[OSM-talk] Tiles at home Update
barry.crabtree at gmail.com
Wed Mar 21 08:57:24 GMT 2007
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.
> > > 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*
> > 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!
> 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
Live as if you were to die tomorrow. Learn as if you were to live
forever. - Gandhi.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the talk