<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Am 28.04.2012 11:29, schrieb Thomas Davie:
<blockquote
cite="mid:F21B132C-F670-4993-897D-C6D486E9021E@gmail.com"
type="cite">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.</blockquote>
I think about the tool being written in Java (as that should be
availlable on most OSs, I think)<br>
The Interface to the renderers could be different<br>
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)<br>
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<br>
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.<br>
<br>
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.<br>
<blockquote
cite="mid:F21B132C-F670-4993-897D-C6D486E9021E@gmail.com"
type="cite">
<div><br>
</div>
<div>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.</div>
</blockquote>
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.<br>
<br>
That's what map designers should get at hand, I think, so that's how
it's a useful tool for mapcss design.<br>
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.<br>
<br>
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.<br>
<br>
regards<br>
Peter<br>
<br>
<blockquote
cite="mid:F21B132C-F670-4993-897D-C6D486E9021E@gmail.com"
type="cite">
<div><br>
</div>
<div>Bob<br>
<div>
<span class="Apple-style-span" style="border-collapse:
separate; color: rgb(0, 0, 0); font-family: Helvetica;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-align: -webkit-auto; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px;
-webkit-text-decorations-in-effect: none;
-webkit-text-size-adjust: auto; -webkit-text-stroke-width:
0px; font-size: medium; ">
<div><span class="Apple-style-span" style="font-family:
Arial; ">
<pre>if (*ra4 != 0xffc78948) { return false; }</pre>
</span></div>
</span>
</div>
<br>
<div>
<div>On 28 Apr 2012, at 10:25, Peter Wendorff wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div>Hi.<br>
I'm not inside MapCSS-Developing currently, but what do
you all think about the idea of implementing a "mapcss
test center".<br>
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...<br>
<br>
I guess, all mapcss implementations should be able to take<br>
1) a mapcss file or string<br>
2) map data (not sure, if here osm.xml is or easily could
be a common base format)<br>
and produce an image out of that.<br>
<br>
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<br>
- write a mapcss-style<br>
- get rendering results of all registered renderers<br>
<br>
This could be used<br>
1) to check rendering results<br>
2) to compare renderings and identify compatibility
problems (between implementations and compared to the
"standard")<br>
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".<br>
<br>
Just an idea - even if I don't have time to work on it.<br>
<br>
regards<br>
Peter<br>
<br>
Am 28.04.2012 10:59, schrieb Komяpa:<br>
<blockquote type="cite">Hello everyone,<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">We all know everyone is willing to
make their renderer the best one.<br>
</blockquote>
<blockquote type="cite">Everyone has own purpuose - some
are targeting on speed, some are<br>
</blockquote>
<blockquote type="cite">willing to provide good editing
experience, some want to just show<br>
</blockquote>
<blockquote type="cite">something to the user...<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">So, what do I propose:<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">1. Count and list active renderer
developers. Those who really have<br>
</blockquote>
<blockquote type="cite">time to fix minor things and want
to have a badge "Supports MapCSS 0.2<br>
</blockquote>
<blockquote type="cite">final".<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">2. Set up a deadline. Something
real, like 1st of June (or July),<br>
</blockquote>
<blockquote type="cite">2012, when a spec will be marked
"final", and all things post this<br>
</blockquote>
<blockquote type="cite">date will go to further
versions/extensions/discussions.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">3. Chop the current draft to
really really basic things. As we see,<br>
</blockquote>
<blockquote type="cite">almost noone supports extrude, not
everyone has support for eval(),<br>
</blockquote>
<blockquote type="cite">.pseudoclasses aren't widely used,
shields aren't implemented in most<br>
</blockquote>
<blockquote type="cite">software, set and exit; ...<br>
</blockquote>
<blockquote type="cite">So, we make a list of core
features that everyone supports or will be<br>
</blockquote>
<blockquote type="cite">able to support in the nearest
time.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">4. Split all the stuff that's
chopped from 0.2 spec into some separate<br>
</blockquote>
<blockquote type="cite">features for further discussion.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">5. Draw beautiful badges "Powered
by MapCSS" for sites and renderers.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">Are there any supporters for this
initiative? :3<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">Why:<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">Lately, I've tried to make a
stylesheet that will look the same in<br>
</blockquote>
<blockquote type="cite">kothic, komap, potlatch and josm,
and wasn't able to do it, because<br>
</blockquote>
<blockquote type="cite">even basic things like
casing-width are handled differently in all of<br>
</blockquote>
<blockquote type="cite">these.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">I just want to have a strict
subset of MapCSS that will work<br>
</blockquote>
<blockquote type="cite">everywhere for sure. :3<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<br>
<br>
_______________________________________________<br>
Mapcss mailing list<br>
<a moz-do-not-send="true"
href="mailto:Mapcss@openstreetmap.org">Mapcss@openstreetmap.org</a><br>
<a class="moz-txt-link-freetext" href="http://lists.openstreetmap.org/listinfo/mapcss">http://lists.openstreetmap.org/listinfo/mapcss</a><br>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Mapcss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Mapcss@openstreetmap.org">Mapcss@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstreetmap.org/listinfo/mapcss">http://lists.openstreetmap.org/listinfo/mapcss</a>
</pre>
</blockquote>
<br>
</body>
</html>