[Tilesathome] New Osmarender/Batik Issue

[Dodi]

Hi Brent,

ok... I didn't see  missing coordinates in MOVE command "M C ...... "  in 
svg path ... you can revert changes I suggested bellow... it was a solution 
for "every area is drawn twice" (you can check it by opening svg in 
inkscape, and ungroup  every group on particular area ...) ... ok, as side 
effect this solution should reduce memory consuption for tiles with 
coastlines :)

You lost your bet, because bezier curve hinting is runing on svg not on osm 
file...  :P

while checking path with id="area_8131246" ...before bezier curve hinting 
... found missing MOVE command also ... so i am looking into osm data
and spotted a problem... but not in osmarender (or partially)... it is 
rather data-integrity problem which osmarender multipolygon support relies 
on...

Situation description: While t at h downloading osm data for tile  2052 1361 
found, that  River Thames consist of  way  id=8131246 and way id=3996343 
joined into multipolygon by relation id=95 ... but way 3996343 has no node 
inside this tile boundary and therefore is not downloaded ...

finaly ... from http://www.freemap.sk/osmarender6.zip you can download 
alpha6 version with these improvements
1) filtered out missing ways from multipolygon relations
2) filtered out missing nodes for your experiments with lowzoom and osmxapi 
:)
3) mulipolygon areas are generated only once (not as many time as count of 
relation members ) [reported by Robert Fitzsimons]

Dodi

----- Original Message ----- 
From: "Brent Easton" <b.easton at exemail.com.au>
To: "Dodi" <dodi at moonbase.sk>
Cc: <tilesathome at openstreetmap.org>
Sent: Sunday, November 25, 2007 1:41 PM
Subject: Re: New Osmarender/Batik Issue


Hi Dodi,

No luck. Comments below.

regards.
brent.

*********** REPLY SEPARATOR  ***********

On 24/11/2007 at 6:30 PM Dodi  wrote:

>Hi Brent,
>this behaviour is same from osmarender4 ...
>
>I spotted this earlier ... but could not decide if it is bug or required
>behaviour designed by 80n. Maybe we should ask him :)
>
>easiest way to stop generating <use xlink:href...> is to comment-out/remove
>
>    <xsl:call-template name="renderArea">
>      <xsl:with-param name="instruction" select="$instruction"/>
>      <xsl:with-param name="pathId" select="concat('area_', at id)"/>
>    </xsl:call-template>
>
>at lines 867-870 in osmarender.xsl

An invalid path is still being generated:

      <g class="waterway-riverbank">
<path id="area_8131246" d="M   C 0,0 529.253504988145,1512.37605217907 
608.078 1725.40444523807  C 609.412910579215,1729.0121290618 
627.685244301117,1728.
   <...etc ...>
1484.06880966549,900.63416072288 1488.707 901.078978881721  C 
1491.01943144629,901.300748887736 1500.318,915.999972194995 1500.318 
915.999972194995 Z"/>
      </g>


>another way is to make area path generation same as way generation (this
>was
>present in osmarender6 alpha 4) but it breaks "beziercurvehinting" without
>svg file preprocessing
>
>..waycleanup.pl  should be used before beziercurve hinting (I mention it
>several time before [
>http://svn.moonbase.sk/FreemapSlovakiaDiSK/waycleanup.pl ]  which produce
>smaller svg by removing unreferenced svg path definition).


Don't quite follow this. waycleanup.pl seems to want to run on a .svg file, 
bet beziercurvehinting is run on the .osm file, so how can it run first? I 
tried running it on the final SVG and while it did remove many lines, it did 
not remove the line with the invalid path.



>Dodi
>
>
>----- Original Message ----- 
>From: "Brent Easton" <b.easton at exemail.com.au>
>To: "Dodi" <dodi at moonbase.sk>
>Cc: <tilesathome at openstreetmap.org>
>Sent: Friday, November 23, 2007 10:52 PM
>Subject: New Osmarender/Batik Issue
>
>
>Hi Dodi,
>
>Sorry to bother you again, but looks like another Osmarender issue:
>
>Tile: 2052 1361
>Way: 8131246 (Thames River, waterway=riverbank)
>
>The data in the .osm file looks fine, but Osmarender is emitting the
>following:
>
>      <g class="waterway-riverbank">
><path id="area_8131246" d="M   C 0,0 529.253504988145,1512.37605217907
>608.078 1725.40444523807
>    <... bunch of nodes removed ...>
>  C 1491.01943144629,901.300748887736 1500.318,915.999972194995 1500.318
>915.999972194995 Z"/>
>        <use xlink:href="#area_8131246" class="waterway-riverbank"/>
>      </g>
>
>Regards,
>Brent.
>____________________________________________________________
>Brent Easton
>Analyst/Programmer
>University of Western Sydney
>Email: b.easton at uws.edu.au


____________________________________________________________
Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton at uws.edu.au