[Tilesathome] Proposal temporay tags -- the solution?

[Knut Arne Bjørndal]

On Sat, Jan 31, 2009 at 12:19:23AM +0000, Heiko Jacobs wrote:
> Knut Arne Bj?rndal <bob+osm at cakebox.net> 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
bob+osm at cakebox.net
bobkare at irc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4167 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tilesathome/attachments/20090131/6b68ed04/attachment.bin>