It would be indeed better if everything could be handled by xslt. But some tasks are too slow and complicated to implement in xslt. I think performance was the main reason why or/p is now default instead of xslt.
I think a way to go is keep osmarender doing reasonable job but try to make [EMAIL PROTECTED] work as fast and good as possible. Area-center preprocessor makes map look sligtly better, but map is still all right if the preprocessor is not used. On Fri, Sep 12, 2008 at 9:23 AM, Knut Arne Bjørndal <[EMAIL PROTECTED]> wrote: > On Fri, Sep 12, 2008 at 10:52:43AM +1200, Rob Reid wrote: >> Jiri Klement wrote the following on 12/09/2008 01:47: >> > I've added the area center preprocessor to svn. For now it's used only >> > by XSLT. XSLT use different algorithm for area center calculation than >> > orp, so problems with neighbouring tiles described by spaeth already >> > exists for XSLT users. So not big deal if Java is not available and >> > area-center preprocessor can't be used. >> To me it does seem like a big deal, surely if we have a process that is >> know to cause inconsistencies in the map we should be trying to fix it >> not implement an additional process that adds more inconsistencies >> depending on what software clients have installed. >> The idea of a preprocessor for this seems like a good one to me >> providing its output is used in both orp and XSLT and resolves the >> inconsistency. I got the impression from when Knut did the area center >> algorithm in XSLT that it was a pain to implement and I imagine it would >> be as much pain again to refine it with any improvements to the >> algorithm so moving this process into the preprocessing stage where we >> can chose what language to implement it in seems sensible. > > I don't think moving this, which really is a part of the rendering > process, out from the renderer is such a good idea. Sure, for [EMAIL > PROTECTED] we > can put in yet another language, but it makes reproducing something > that looks like the [EMAIL PROTECTED] output in SVG even harder, and it's > already > too many steps. Not to mention making it work in something like > osmarender-frontend. > > The problem with refining the algorithm as it's currently implemented > is A) coming up with the actual refinements and B) finding the time to > do it. B really is the problem, and also the reason I haven't fixed > the areacenter implementation in or/p. Getting areacenter to work was > quite a bit of work, but it's much easier to change small parts than > it is to come up with a way to do the whole thing from scratch. > > -- > Knut Arne Bjørndal > aka Bob Kåre > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > _______________________________________________ > Tilesathome mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/tilesathome > > _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
