[Mapcss] MapCSS 0.2 finalization

Paul Hartmann phaaurlt at googlemail.com
Tue May 1 11:38:31 BST 2012


On 05/01/2012 11:14 AM, Komяpa wrote:
> Hi all,
> 
> 
> 
> A couple of questions to discuss:
> 
> 0) schedule.
> 
> Will it be fine for developers to implement some obvious changes in
> their engines till 15th of May, marking respective rows in the table,
> so we'll have less differences before we start discussing other stuff?
> Two weekends during that period :3
> 
> so, proposed schedule:
> 
> may 1-15: trying to fill more details about your renderer into that
> table, showing weaknesses of others and own strenghts, and trying to
> implement the most of things the others do to be compatible.
> may 15-21: re-partitioning of the table into a "green" release-ready
> part and the "proposed" part for future discussion.
> may 20-30: writing text-form spec from green part of table.
> 
> Any objections?
> 
> 
> 1) meta{}.
> 
> That thing was used as josm's standard way to store info about
> stylesheet, like its name and author.
> 
> I think it's worth it - even if most will just ignore its content, it
> can be used to store mapcss revision number and be used by something
> like libmagic to guess that it's mapcss file at all.
> 
> 2) testing stylesheet.
> 
> For now some developers use openstreetmap.by's komap-in-mind
> stylesheet, http://kothic.googlecode.com/hg/src/styles/osmosnimki-maps.mapcss
> 
> It has advantages of being long (so you can check performance),
> beautifully-rendered (if done right), and has something like reference
> rendering, http://openstreetmap.by itself.
> 
> Obvious problems are that it was written being strongly coupled with
> komap - it has a lot of -x-properties in it and even some hardcoded
> hacks to be nice. Also, some problems of mapnik, like inability to
> cascade rules, sneaked into it too.
> 
> I think we need some shorter sheet that will just utilize all the
> stuff that will go to the standard. Maybe we should revisit that after
> 15th of May, if everyone agrees.
> 
> 

Hi,

I think the schedule is too tight, for serious code changes, I'd plan at
least 1 month. Maybe it is sufficient if the maintainer says:

"In principle I'm Ok with this - I'll make the change the next time I
work on the renderer and I will except patches that help to get there."

This table is great to get things going, but it's not suitable for
longer discussions. This is maybe the last opportunity to make major
changes without too much pita, so it's worth thinking some stuff through
again. There are a few points that bother me in particular, I guess I'll
raise them one after the other on the mailing list. :)

Paul



More information about the Mapcss mailing list