The current structure of the rules file does lead to quite a lot of repetition. As Knut Arne says a two pass Osmarender is undesirable.
The solution? Have a meta rule files that is used to generate the real rules file. The meta file could describe in logical, non-repetative terms what is needed, and then a simple XSL template or perl script could be used to generate the rules file. This would be easy. The hard bit is coming up with the meta rules file... 80n On Sat, Jan 31, 2009 at 10:25 AM, Knut Arne Bjørndal <[email protected]<bob%[email protected]> > wrote: > On Sat, Jan 31, 2009 at 12:19:23AM +0000, Heiko Jacobs wrote: > > Knut Arne Bj?rndal <[email protected] <bob%[email protected]>> wrote: > > >> Is this use of "temporary tags" possible in XSLT and perl? > > >> Does anyone can code it for XSLT- and perl-verion, if this > > >> new feature is possible and makes sense and makes sense and if it > > >> doesn't make processing slow or other unwanted side effects? > > > > > > It sounds like a very hard thing to implement in XSLT, you can't > > > really change the input document, only look at the input and produce > > > output, with state pretty much only moving around through arguments to > > > other templates. > > > > Mmmm.... "only look at input and produce output"... > > It seems, that my idea needs a two-step-processing in XSLT > > (perl might be one step...) > > We've thought about using a two-step process before, but it > complicates things for everything that wants to use osmarender, which > makes it a bad idea. And it's bound to slow things down a bit, loading > both rules and input osm data takes a while. > > > > If what you are doing here is about adjusting the width of something, > > > have you considered using something like the honor-width code? It > > > scales things according to the width in meters on the ground, and > > > doesn't involve nesting rules within rules within rules within rules. > > > > No, that doesn't help... width is only an example... > > > > I used "pseudocode", because contents of a rule doesn't matter. > > I disagree, it does matter, because it means I can understand what it > is you want to accomplish, not just how you think it can be > accomplished. > > > A lot of nesting matters ... And again and again very similar nestings... > > I don't think nesting has to be a bad thing, but > nearly-but-not-quite-identical blocks of rules are a bad thing since > it's very easy to copy them around and forget one change somewhere. > > The class trickle thing is a simple thing which helps move common > differences out from the inner rules into the common one. > > So for example: > <rule bridge-casing> > <set class="bridge casing"/> > <rule railway=nicerail|otherrail|whatever> > <set class="railway" > <rule railway=nicerail> > <line class="nicerail"/> > </rule> > <rule railway=otherrail> > <line class="otherrail"/> > </rule> > ... > </rule> > and then highways... > </rule> > ... > <rule bridge-core> > <set class="bridge core"/> > <rule railway=nicerail> > <line class="nicerail"/> > </rule> > <rule railway=otherrail> > <line class="otherrail"/> > </rule> > ... > </rule> > > Combined with hughbris's changes to use CSS in a sensible way this is > then used with CSS like this: > .bridge.casing { > some general rules; > } > .bridge.casing.railway { > some things that apply to all railways; > } > .bridge.casing.railway.nicerail { > width: 3px; > } > > > I try to write my idea according to a two-step-solution. > > First step should be possible for XSLT, because it only adds something. > > > > Again our way: > > > > <way id=... > > > <nd ...> > > <tag k=railway v=nicerail /> > > <tag k=detail v=anything /> > > </way> > > > > the style file get a new section. > > In front of <rules>...</rules> there might be a section > > <retag>...</retag>, that makes from data.osm a file temporary.osm > > that is read in the second step. > > > > Using a rule like: > > > > <rule e=way k=railway v=nicerail> > > <rule e=way k=detail v=anything> > > <set k=$width v=nicewidth /> > > </rule> > > </rule> > > > > The result should be in temporary.osm: > > > > <way id=... > > > <nd ...> > > <tag k=railway v=nicerail /> > > <tag k=detail v=anything /> > > <tag k=$width v=nicewidth /> > > </way> > > > > for every railway of sort railway=nicerail combined with detail=anything. > > Other combinations like railway=otherrail or railway=nicerail detail=xxx > > may get $width=anotherwidth > > > > the "$" only should avoid conflicts with real existing tags, > > because anyone might use key-names like our temporary keys for > > other purposes. You may use # or ? or anything else, only > > documentation is needed, that this letter shouldn't be used > > for tagging in real world... > > > > The first step may also do a job standing alone for re-tagging > > some short cuts > > > > changing > > > > <way id=... > > > <nd ...> > > <tag k=highway v=cycleway /> > > </way> > > > > to > > > > <way id=... > > > <nd ...> > > <tag k=highway v=path /> > > <tag k=bicycle v=designated /> > > </way> > > > > may be one example, that can simplify rules, because now you > > have to code every cycleway-rule twice: one for cycleway, one > > for path/designated. > > Or the other way around, to have that disaster of a tagging scheme > look like something sensible. > > > But for my idea also the second step is needed: > > > > For all sorts of railways only one rule is still needed in > > the rules-section: > > > > <rule e=way k=bridge v=yes > > > <rule e=way k=railway v=* > > > <line class="bridge-casing bridge-{$width}-casing" /> > > </rule> > > </rule> > > > > I don't know, if the notation "{$width}" is a good solution, it's > > an example, how it may coded... > > If XSLT has less problems using another coding inside rule file, > > this should be used... > > > > Osmarender has to look at the string between "<line" and "/> > > If it find's a "{...}" in the string it should take the string > > inside it as name of a key of th actual way, here "$width" and should > > replace it by the value. > > Wrong, when using a proper XML parser XML stops being text and becomes > a node-tree. It would have to look in every parameter in every > instruction separately, and if I remember correctly there isn't a > single place to put this, which makes it a very big change. > > Also, please consider what happens if, for some reason, you end up > not rewriting that element to have the $width tag. You then get a > reference to the non-existant bridge--casing class. Inkscape will > probably just ignore it, but sensible parsers like Batik will throw an > error to tell you this. So it effectively makes osmarender a lot more > error-prone. > > <cut> > > And it is needed more then once for transforming things like > > <line class="{$a}-{$b} {$c}" {$d} /> > > > > $d may contain for example smart-linecap=no or nothing > > This looks like it would very fast get very brittle. Also, it would > require you to constantly look two places at once while editing the > rules, to actually understand what is happening. Add to this that you > already often have to look at both the rules and the CSS and even big > modern screens start becoming small. > > > the advantages: > > - breaking large nestings in smaller nestings > > Why is nesting such a bad thing? > > > I hope, my idea is a little bit better explained now? :-) > > Yes, I think I understand what you're trying to accomplish, but I > disagree and think it would end up being harder to understand and work > with. > > The Osmarender stylesheets need improvements, but I don't think this > is it. > > -- > Knut Arne Bjørndal > aka Bob Kåre > [email protected] <bob%[email protected]> > bobk...@irc > > _______________________________________________ > Tilesathome mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/tilesathome > >
_______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
