Am 28.04.2012 11:29, schrieb Thomas Davie:
I like the idea, though I'm not 100% certain how the tool would call
out to the various renderers -- there is at least one (mine) which
reqires a runtime only available on one OS.
I think about the tool being written in Java (as that should be
availlable on most OSs, I think)
The Interface to the renderers could be different
1) "server-client style": define some kind of a http request defining
data and stylesheet, and a url and port that the renderer can support
(would even allow to use renderers running on different OSes, like in a
virtual machine)
2) "exec" style: define a shell command to run (slightly different
depending on OS, but there should be libraries to do that more or less
OS independent from Java
3) "include" style: for java implementations even running the code
included as a jar file could work, if a common mapcss-renderer-interface
would be implemented.
Which renderers to compare and test could be decided by the user (e.g.
with some presets), depending on the Operating System and defined using
a config file, that can be exchanged arbitrarily.
I'd also toyed with the idea of having reference renderings, like the
CSS implementers do, but this becomes problematic without specifying
things like label positioning algorithms, and conflicting label choice
algorithms.
Sure: There may be differences, but comparing renderers does not (only)
mean validating them. Validation is not easily possible on unspecified
issues, and definitively not automatically possible, but thats similar
to the needs designers have for websites: You can follow the HTML and
CSS standards, but that doesn't make sure that the website looks good or
even acceptable in all browsers.
That's what map designers should get at hand, I think, so that's how
it's a useful tool for mapcss design.
For you as mapcss renderer developers it's a useful tool as you can
compare between renderers and decide on your own, which differences are
acceptable, and which look like a conflict according to the specs and
common sense.
This may include judgements like: "these highways look different, but
only, as A did not support multi-color-dotted casings, yet" or something
like that, and that's fine, too.
regards
Peter
Bob
if (*ra4 != 0xffc78948) { return false; }
On 28 Apr 2012, at 10:25, Peter Wendorff wrote:
Hi.
I'm not inside MapCSS-Developing currently, but what do you all think
about the idea of implementing a "mapcss test center".
It's a idea that came to my mind while reading the last messages on
the list, so probably it's a bad one, but who knows...
I guess, all mapcss implementations should be able to take
1) a mapcss file or string
2) map data (not sure, if here osm.xml is or easily could be a common
base format)
and produce an image out of that.
What about implementing this into e.g. a java toolkit (java, because
it's running on any major OS usually), that enables the user to
- write a mapcss-style
- get rendering results of all registered renderers
This could be used
1) to check rendering results
2) to compare renderings and identify compatibility problems (between
implementations and compared to the "standard")
3) as a design tool for style designers, including mapcss validation,
probably giving hints or helping with "shortcomings" like the idea
proposed by Thomas about nesting rules - as the tool could give an
option for "make more specialized rule".
Just an idea - even if I don't have time to work on it.
regards
Peter
Am 28.04.2012 10:59, schrieb Kom?pa:
Hello everyone,
We all know everyone is willing to make their renderer the best one.
Everyone has own purpuose - some are targeting on speed, some are
willing to provide good editing experience, some want to just show
something to the user...
So, what do I propose:
1. Count and list active renderer developers. Those who really have
time to fix minor things and want to have a badge "Supports MapCSS 0.2
final".
2. Set up a deadline. Something real, like 1st of June (or July),
2012, when a spec will be marked "final", and all things post this
date will go to further versions/extensions/discussions.
3. Chop the current draft to really really basic things. As we see,
almost noone supports extrude, not everyone has support for eval(),
.pseudoclasses aren't widely used, shields aren't implemented in most
software, set and exit; ...
So, we make a list of core features that everyone supports or will be
able to support in the nearest time.
4. Split all the stuff that's chopped from 0.2 spec into some separate
features for further discussion.
5. Draw beautiful badges "Powered by MapCSS" for sites and renderers.
Are there any supporters for this initiative? :3
Why:
Lately, I've tried to make a stylesheet that will look the same in
kothic, komap, potlatch and josm, and wasn't able to do it, because
even basic things like casing-width are handled differently in all of
these.
I just want to have a strict subset of MapCSS that will work
everywhere for sure. :3
_______________________________________________
Mapcss mailing list
[email protected] <mailto:[email protected]>
http://lists.openstreetmap.org/listinfo/mapcss
_______________________________________________
Mapcss mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/mapcss
_______________________________________________
Mapcss mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/mapcss
