[Tilesathome] New preprocessor - area center

[Jiri Klement]

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 t at h 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 <bob+osm at cakebox.net> 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 t at h we
> can put in yet another language, but it makes reproducing something
> that looks like the t at h 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
> bob+osm at cakebox.net
> bobkare at irc
>
> _______________________________________________
> Tilesathome mailing list
> Tilesathome at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tilesathome
>
>