[Tilesathome] Using Batik to render tiles instead of Inkscape

[Dodi]

I think,  lines2curves.pl at lines 214-219

        if ($way_id =~ /way_/ && dup_points(\@path_points)) {
            $bezier_path_string .= "M$path_string$postfix";   # <---- this
cause "MM"
        } else {
            $bezier_path_string
                .= 'M'.from_lines_to_curves(\@path_points,
$way_id).$postfix;
        }

cause the "MM" problem, in case when way has duplicate nodes (every "area"
has dup_points, because first and last nodes are identical)... another "M"
is attached to original path_string...

changing line 215 to :
 $bezier_path_string .= "$path_string$postfix";

should fix this...

Dodi

----- Original Message ----- 
From: "Brent Easton" <b.easton at exemail.com.au>
To: <tilesathome at openstreetmap.org>
Sent: Friday, October 05, 2007 9:43 AM
Subject: [Tilesathome] Using Batik to render tiles instead of Inkscape


> Due to the current issues with Inkscape, I have been investigating using 
> Batik to render image tiles. The Batik distribution includes a utility 
> rasterizer program to do just this. Had a few problems getting it running, 
> but my findings so far are:
>
>
> The job stream is generating illegal svg that Batik is choking on. 
> Inkscape must be quietly ignoring the errors. So far:
>
>
> 1. CSS error in .untagged-segments in z12 and z13
>
>            .untagged-segments {
>                stroke-width: 0.5px;
>                stroke-linejoin: round;
>                stroke-linecap: butt;
>                stroke: #e0e0e0;
>                stroke-dasharray: 0.5,0.5;
>            }
>
> 'butt' is not a valid option for stroke-linejoin. should be round?  Will 
> go away in Osmarender 6.
>
> 2. CSS error in .city_caption in z14
>
> .city-caption           { font-size: 14px; opacity: 50%; }
>
> "50%" is not a valid option for opacity. Should be 0.5
>
>
> 3. Illegal descriptor in <Path>
>
> <path id="way_end_4981047" d="MM1441.97899999995 
> 1048.96107085533L1441.97899999995 1048.96107085533"/>
> <path id="way_normal_4981078" d="M 1182.88799999988 
> 429.774486661176L1192.23699999992,469.054969928261L1201.58599999996,508.333043571463L1210.09699999973,544.088247139217"/>
> <path id="way_start_4981078" d="M 1182.88799999988 
> 429.774486661176L1187.80852631569,450.448425222799"/>
>
> See the MM in the first line. I have not been able to work out why this is 
> happening, but it is a more serious issue. Presumable Inkscape is just 
> ignoring this as well.
>
> This only occurs in some ways in some tiles. I got this on a motorway way 
> on tile 3763 2458. There where 3 cases if 'MM'
>
> For an acid test, I tried central Sydney (3768, 2458). After fixing the 
> 580 occurences of 'MM' (changed to 'M '), the rasterizer happily rendered 
> the z12 svg into a png tile in about 25 seconds, using a peak memory of 
> 300Mb. If anything the output looks better than the Inkscape version.
> Doing the same thing manually with Inkscape (open, then export) took 
> several minutes and 550Mb of memory.
>
> I believe this is looking very promising, It's sort of like using a can 
> opener to open a can instead of a $100,000 industrial robot :)
>
> Can someone have a look at the 'MM' problem. It's sort of like using a can 
> opener to open a can instead of a $100,000 industrial robot :) I had a 
> look at Osmarender.xsl, but could not see how it can happen.
>
> If we can solve this, I will try and do a full test implementation.
>
> Cheers,
> Brent.
>
>
> ____________________________________________________________
> Brent Easton
> Analyst/Programmer
> University of Western Sydney
> Email: b.easton at uws.edu.au
>
>
> _______________________________________________
> Tilesathome mailing list
> Tilesathome at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
>