[OSM-dev] Proposal: Database accelerator and dirty tile marker based on simple algorithm.

[Nigel Magnay]

> > And what good is that geodata if you can't get at it accurately,
> > and quickly?
>
> Perhaps you should try your skill as a poet rather than a C
> programmer.  You seem to do quite well with the rhetoric style.
>
What part of GRASS is not applicable to OSM?  Their way of doing
> quad trees is not useful for us?  So we have to write our own?
> Their way of doing quad trees is only useful for proprietary data,
> and to create free geodata OSM has to reinvent all the algorithms?


I don't know where you get that from. I don't know GRASS, what it is, or
even that it exists. Perhaps, rather than sitting from the sidelines
throwing rocks you might actually contribute something useful - like, say,
how they approach the problem? Perhaps we'll all agree that it's great and
adopt it outright. Or maybe we will look at it and find an improvement based
on our specific use-case.

I've looked at what we're doing right now, and I want to make it better. I'm
not criticizing, say, choosing Ruby for a server, or using XSLT to generate
maps, or writing utilities in Perl, even if I happen to think some of those
things are not the best way of doing things, because I don't have the time
to re-do everything myself. I do care about how the data is stored because
it could make, for example, a low-footprint OSM server much easier to
implement. And I think it would have a benefit for all OSM users.

The fact of the matter is that what we are doing today is storing and
retreiving data in a way that is demonstrably not ideal. I have attempted to
describe why, and been discussing with various people, such as Nick, a way
that it might be solved, and I'm interested in why and where there are
choices to be made. I could, for example, point out that google use pretty
much exactly the format that I'm suggesting, but it would seem a little
unreasonable to follow a path of 'well, they do it that way and they're
almost always right'.


> frankly, find your suggestion that this is 'harmful to OSM'
> > /astonishingly/ rude.
>
> If that astounds you, fasten your seatbelt.  Bumpy road ahead.


So you first criticise a technical discussion for being 'harmful to OSM',
and you follow up with that?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20060918/898df027/attachment.html>