Knut Arne Bj?rndal <[email protected]> wrote:
>> I also put it in the wiki:
>> http://wiki.openstreetmap.org/wiki/Osmarender/Proposal_Temporary_Tags
>
> Can we please keep this discussion in one place, instead of splitting
> it between the list, trac and the wiki?
I don't know, where I have the largest chance to met the heroe,
who can code my wishes ;-)
> For now I'll just comment here.
ok
> I don't really understand what you're trying to do, your psuedocode is
> even less legible than most XML, and you haven't really explained what
> you are actually trying to do.
I try to explain it again ...
>> 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...)
> /Maybe/ something could be hacked together using exslt:node-set, but I
> think it would still be way too complex.
after google to node-set... Mmmm... might be...
> 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.
A lot of nesting matters ... And again and again very similar nestings...
I try to make a simple example first...
Let us view to this way:
<way id=... >
<nd ...>
<tag k=railway v=nicerail />
<tag k=detail v=anything />
</way>
Let us assume, that my rendering of railways should have 4 different
widhts: very_small types of railways, small ones, middle, wide
Normally I would write
<rule e=way k=railway v=nicerail>
<rule e=way k=detail v=anything>
<line class="bridge-casing bridge-nicerail-casing" />
</rule>
</rule>
and nearly the same for the other 3 classes.
and nearly the same for bridge core, casing, core, tunnel, text, ...
at the end something like
.bridge-nicerail-casing { stroke-width: 1px; }
Look at my example, how complex the nesting of rules would be,
if I don't want only to decide for nicrail and anything, but
some things more...
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.
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.
So if Osmarender verifys
<rule e=way k=bridge v=yes >
<rule e=way k=railway v=* >
from above and finds out, that our way
<way id=... >
<nd ...>
<tag k=railway v=nicerail />
<tag k=detail v=anything />
<tag k=$width v=nicewidth />
</way>
matches this rule, it should first transform
<line class="bridge-casing bridge-{$width}-casing" />
using
<tag k=$width v=nicewidth />
to
<line class="bridge-casing bridge-nicewidth-casing" />
Or if the matching way has
<tag k=$width v=anotherwidth />
the result of transforming
<line class="bridge-casing bridge-{$width}-casing" />
would be
<line class="bridge-casing bridge-anotherwidth-casing" />
the suitable CSS then are
.bridge-nicewidth-casing { stroke-width: 1px; }
.bridge-anotherwidth-casing { stroke-width: 2px; }
Step one should be the original function of XSLT: transforming
one XML to another one, no problem when splitting to two steps?
For step two it needs capability of string processing.
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
the advantages:
- breaking large nestings in smaller nestings
e.g. combinations of colors and widths
<line class="{$a}-color {$b}-width" />
instead of
<rules>
<rule for bridges>
<rule for width>
<rule for color>
<line class="x1-color y1-width" />
</rule>
<else>
<line class="x2-color y1-width" />
</else>
</rule>
<else>
<same rule for color again>
<line class="x1-color y2-width" />
</rule>
<else>
<line class="x2-color y2-width" />
</else>
</else>
</rule>
</rules>
then
<retag>
<rule for color>
<set k=$x v=x1>
</rule>
<else>
<set k=$x v=x2>
</else>
<rule for width>
<set k=$y v=y1>
</rule>
<else>
<set k=$y v=y2>
</else>
</retag>
<rules>
<rule for bridges>
<line class="{$x}-color {$y}-width" />
</rule>
</rules>
Simple nesting, very simple drawing rules, less exactly the
same code sniplets twice and more in file
If you only have 2x2 cases like in this case, you may not code such
things, but if you have 4x2x3x8x... cases, that you want to render
differently...
- reuse of nested rule results needed more then once
If you have 4 sorts of widths of casings you also have the same
4 sorts of widths of cores and 4 sorts of widths of ...
the exact widht in px is different, but therefor CSS is used
the *classes* of widths should be the same for bridges, lines, tunnels,
disused, construction, ... a wide core doesn't need a small bridge...
So setting a temporary width class at the beginning may be reused
many times in the rules ...
Same with colors or dashing or ...
I hope, my idea is a little bit better explained now? :-)
MfG Heiko Jacobs Z! IRCnet Mueck
--
Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542
Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de
Couleurstud. Infos cousin.de VCD, umwelt&verkehr KA umverka.de
_______________________________________________
Tilesathome mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/tilesathome
