[Tilesathome] New Osmarender/Batik Issue

Dodi dodi at moonbase.sk
Tue Nov 27 21:38:22 GMT 2007 

Hi Brent,

at  http://www.freemap.sk/osmarender6.zip is newer version which has no 
NaN's for tile 235 153 8

but i still recommend to add smart-linecap="no" to every <line>  rule in low 
zoom map-features files ...  using then has no visual outcome for 
lowzoomlevel tiles but svg file is about 15% smaller, aditional 
"waycleaning" gives only about 25% of original SVG size, and if waycleaning 
is used before bezier curve hinting it brings more smooth curves at line 
joins (because of way how lines2curves.pl works)

...and for  nicer osmarender map layer I have small modification for 
tilesGen.pl with tile antialising

http://c.tah.openstreetmap.org/Tiles/tile/12/2271/1415.png
vs .
http://c.tah.openstreetmap.org/Tiles/tile/12/2272/1415.png

you can discover visible difference on tertiary roads

or http://wiki.openstreetmap.org/index.php/Image:Tile_antialiasing.png  for 
same tile side-by-side with and without antialiasing

Would we like to use this improvement for whole osmarender layer ???

Regards,
Dodi

----- Original Message ----- 
From: "Dodi" <dodi at moonbase.sk>
To: <b.easton at uws.edu.au>
Cc: <tilesathome at openstreetmap.org>
Sent: Monday, November 26, 2007 11:00 PM
Subject: Re: [Tilesathome] New Osmarender/Batik Issue


> 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
>
>
>
> _______________________________________________
> Tilesathome mailing list
> Tilesathome at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
>

More information about the Tilesathome mailing list