[OSM-dev] [OSM-talk] Ideas for OSM enhancements

[Karl Newman]

On Jan 1, 2008 8:36 PM, Brett Henderson <brett at bretth.com> wrote:
> Karl Newman wrote:
> > No problem. It'll certainly be later, not sooner. By the way, I'm
> > writing a bunch of JUnit tests, mostly for the stuff I'm doing or have
> > done and I encountered an exception when testing the area filter with
> > completeWays. It's related to the SimpleObjectStore (probably the
> > recent single class store changes), but I haven't traced it down. I
> > attached my test fixture as a patch (hopefully it works; I pruned out
> > some files from the patch which are work-in-progress).
> >
> > Karl
> >
> Thanks.  I've possibly broken a few things at the moment.  I've done
> some manual testing to weed out the obvious breakages but no doubt
> there's more.  I recently found broken end of stream detection, that
> might be your issue ...  The lack of unit tests is bad form on my
> behalf, they're definitely needed.
>

No problem; I'll try to make sure I supply complete test coverage for
the stuff I contribute at least. If I get inspired I'll write tests
for some other parts... I'm new to unit testing in general, but I'm
definitely sold. I wrote some tests for one function that I thought
was trivial and discovered an error where I swapped two arguments...
Plus, writing the tests helped me think through the solution for a
couple weird functions, and having a complete set of tests gave me
confidence to try some variations. I tried to guess at the structure
you had set up for your tests; feel free to rearrange things.

> Give me a yell if you have trouble with the recent changes, I've changed
> a number of the store classes.  They've gotten a bit more complicated to
> support some of the new "dataset" code I'm adding.  The single class
> versus generic class serialisation is a bit messy but I wanted a way to
> minimise the size of on-disk data when the class type is known.
> Previously it wrote a class type identifier before every object which
> was redundant in many cases.  It didn't matter too much when the objects
> themselves were large but I'm now serialising index element objects
> which are tiny (tile int plus a long entity id, or long entity id plus a
> long file offset) and the overhead increased.
>
> Hopefully I'm not turning your life into merge hell ;-)
>

No, I svn up like a nervous habit to keep the changes small, and
really I haven't had any conflicts and very few merges (most of my
changes have been isolated in developing the new Bounds class, but now
I'm nearly done with incorporating it into the tasks. I just got
nervous about some changes I was making and so I stopped to write some
tests.

I've been seeing the classnames that you've been committing--I think
the Dataset will be a great help for writing a "tiling" task. One
thing to think about--it might be nice to support writing out the
Dataset (to a SQLite file or whatever) and then allow it to be reused
on a future invocation, to avoid re-parsing a file. Maybe you're
already planning to do this; I haven't looked closely.

Thanks,

Karl