[OSM-talk] Tiles at home Update

80n 80n80n at gmail.com
Wed Mar 21 09:06:36 GMT 2007


On 3/21/07, Barry Crabtree <barry.crabtree at gmail.com> wrote:
> Hi
>
> On 3/21/07, 80n <80n80n at gmail.com> wrote:
> > On 3/20/07, Dirk-Lüder Kreie <osm-list at deelkar.net> wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > 80n schrieb:
> > >
> > > > It also utilises a pre-processor (called Frollo) which sorts out the
> > > > ordering and direction of segments.  Segments that are mis-ordered or
> > > > pointing in the wrong direction will no longer cause so much of a
> > > > problem on the rendered tiles.  There should be a visible improvement
> > > > in areas, where a mis-ordered segment could often cause great big
> > > > triangular holes.  There should also be an improvement to the
> > > > rendering of street names.  There should be fewer chopped up and
> > > > inverted street names.
>
> Excellent!
>
> > > >
> > > > The Frollo pre-processor is designed specifically for use with
> > > > Osmarender, but both Frollo and Osmarender can be used on their own.
> > > > Frollo may be useful for anything that needs to have the segments
> > > > sorted into a sensible order.  More details here:
> > > >
> http://wiki.openstreetmap.org/index.php/Osmarender/Frollo
> > >
> > > While I like the new osmarender styles and small fixes I'm against the
> > > usage of this preprocessor for the tiles at home layer.
> > > The errors should be fixed in the source data, not at the renderer.
> >
> > You can use Frollo to do this.  Download an area, run Frollo, and then
> > upload using JOSM.
>
> Agreed you can use Frollo for this, but its a more general problem, and the
> closer the fix can get to the source, the better it will be overall. I don't
> know enough about the overall architecture, but can't Frollo be made to run
> as part of the api call to retrieve the data in the first place, so that
> *anything* that gets data from the api will not have to remember to 'clean'
> it with a pre-processor first.
>
> I'm going to have the same issue with the bezier curves. I'm writing that as
> a pre-process step to osmarender, but think that it is another in (in this
> case maybe conditional) processing step that should be done at the server
> before the data leaves the api. In the future JOSM or some other editor
> might decide to draw bezier curves. The user shouldn't have to remember to
> run a pre-processor to get the data in the right form, it should just *be*
> right!

I've noticed that recent versions of JOSM seem to be doing some kind
of segment re-ordering if you add or remove segments from a way, so
perhaps this will become less of a problem as time goes by.



>
> > >
> > > Besides Frollo seems to have problems with it's max recursion in some
> > > areas, like z12 2035 1350 where it also takes *ages* (step I ran for
> > > more than 15 minutes CPU time, step II used 12 minutes) just to
> > > "Frolloize" the data, not mentioning the enormous amount of RAM it uses
> > > there.
> >
> > Ways that contain a very large number of segments (several hundred)
> > will cause this.  My testing didn't uncover anywhere that was a
> > practical problem but I'll look at the area you have referenced.  All
> > that's needed is an index to speed it up.  Just didn't think it was
> > necessary - but it obviously is.
> >
> >
> > >
> > > Seeing how long my 1Ghz renderer takes for that tile I can load that
> > > area manually and look for any inconsistencies (with mappaint plugin and
> > > segment order numbers activated) concerning segment orientation and
> > > ordering, upload again and render with Cambridge.
> > >
> > > I'm seriously considering to disable Frollo on my clients at the least.
> >
> > I hope we can avoid that :)
>
> Me too :-) the results are worth it!
>
> Cheers. Baz.
>
> > > Wikipedia doesn't run a spellchecker on it's data, it's the users that
> > > correct misspellings. OSM should work the same IMO.
> >
> >
> > >
> > > Dirk-Lüder "Deelkar" Kreie
> > >
> > >
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.4.6 (GNU/Linux)
> > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> > >
> > >
> iD8DBQFGAE6sFUbODdpRVDwRAst3AJ9qULwf9zfUT3JEilGJXGKT6VBKUQCgzEs7
> > > +tb7Uq9rZxu927feoIm7pF4=
> > > =0pXJ
> > > -----END PGP SIGNATURE-----
> > >
> >
> > _______________________________________________
> > talk mailing list
> > talk at openstreetmap.org
> >
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
> >
>
>
>
> --
> Live as if you were to die tomorrow. Learn as if you were to live forever.
> - Gandhi.




More information about the talk mailing list