<br><br><div class="gmail_quote">On Fri, Jul 29, 2011 at 11:56 AM, Richard Fairhurst <span dir="ltr"><<a href="mailto:richard@systemed.net">richard@systemed.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br></div>Perhaps one day Maperitive might parse MapCSS<br>styles optionally, just as JOSM allows you to choose between MapCSS and its<br>own MapPaint styles?</blockquote><div><br></div><div>Once I (hopefully) extend Maperitive with Python bindings,  I see no obstacles for someone (maybe even me) writing a MapCSS parser in Python and using those bindings to render the maps appropriately.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">You are of course right that declarative CSS-type rules will be slower to<br>
parse (though web browsers seem to manage it fairly quickly ;) ). But<br>
computers get faster, and for some people simplicity and universality are an<br>
adequate trade-off for speed. </blockquote><div><br></div><div>I see no problem with MapCSS when you have all of the geo data pre-loaded into memory. But I do see a problem if you have a planet-size PostGIS database, for one simple reason - workflow:</div>
<div><ul><li>In MapCSS I would have to go through the list of all geo elements and apply any matching MapCSS styling rules to produce a graphic element.</li><li>Maperitive goes through the list of all rules and finds any matching geo elements (using rule selectors) for each rule. Then for each matching geo element a series of commands is executed which produce one or more graphic elements.</li>
</ul></div><div> In a large database going through the list of all geo elements (even if bound-boxed) would be prohibitively expensive. It's true that computers get faster, but the planet.osm gets bigger, too :)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Given that my doubtless-inefficient rules<br>
engine works tolerably quickly on Adobe's dog-slow Flash Player for Mac, I<br>
suspect one done by a proper programmer in a proper environment could be<br>
"fast enough" for many people. <br></blockquote><div><br></div><div>I agree... Back then I was hoping to create a system that would be easy to use/write but still powerful enough for DB-based rendering with all OSM idiosyncrasies. Now that I've abandoned those foolish dreams, my hope is to provide something for different kinds of users.</div>
<div> </div><div>Igor</div></div>