[Tilesathome] New Osmarender/Batik Issue

Mon Nov 26 22:00:09 GMT 2007

Hi Brent,
yes it wasn't a total solution for this problem, but significantly reduced 
the number of NaN's  :) thye are now only in svg path generated by 
osmarender's "smart-linecap" magic...  for lowzoomlevels actually no need to 
use smart line caps, so we can add  smart-linecap='no' to every lowzoom 
<line> rule and there will be no more NaN's :)

...will try to remove rest of NaN's...

Dodi

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

Hi Dodi,

Your new Osmarender.xsl has fixed one of the problems (Thames riverbank), 
but when I try

perl tilesgen.pl xy 235 153 8

I am still getting 'Nan's due to ways referencing nodes that are not 
included in the .osm file.

Regards,
Brent.

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

On 25/11/2007 at 4:48 PM Dodi  wrote:

>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

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