[OSM-talk] Re: [OSM-dev] MassGIS dataset
crschmidt at crschmidt.net
Sun Jun 4 13:34:58 BST 2006
On Sun, Jun 04, 2006 at 01:01:43PM +0100, SteveC wrote:
> > Since there's been a request *not* to grab large chunks of data via the
> > API, what exactly do you expect would be a decent demo? I'm glad to give
> > you a demo to do whatevery ou want with, but for my needs, OSM can't
> > serve them at the moment.
> As far as I know your needs (openlayers using OSM data for where 2.0?
> I've had to skim email) don't intersect well with most other OSM users.
Note that this question wasn't geared to my needs, it was geared towards
Lars' suggestion of a 'proof of concept'. I understnad that my needs and
OSM's needs don't intersect, but Lars seems to think that I could
contribute something useful -- which I don't agree with. With the
current technical state of OSM, there's nothing I can do to create a
useful proof of concept, in my opinion. If someone from within the OSM
project disagrees, then I'd like to hear what I can or should do,
because I'd like to prove how OSM can be used usefully.
> NickW's rendering work does intersect because it improves the rendering
> of the existing view/edit/upload cycle. Integrating openlayers instead
> of using the hacked anselm tile.js would be great too, or improving the
> node query (which I'm sold on, it just needs the table locking /
> transaction work, I'm not convinced that querys won't clash without
> that) is cool.
What proof can I offer? What more can I do? Give me a case where you
think there will be problems, and I'll do my best to see that there
aren't. Without some idea of what you think will break, I can't convince
you otherwise, and neither can anyone else. We've had three people with
experience in databases looking at the way OSM does things, offering
advice, or offering to help improve things... but no one other than you
understands your concerns.
> The specific pledge you raised is poor from the social angle, it's not
> the way things should go. From the technical angle, it'd be great to
> have another db machine but from the financial angle it's chicken and
> egg to fulfill your request.
Which I understand and accept. You run the project, you make the
decisions, and that's your decision, c'est la vie.
More information about the talk