Re: [OpenMap Users] Process for Change ??

From: JR Andreassen <>
Date: Wed, 07 Feb 2007 18:11:22 -0600

Thanks for getting back to me.

>> I have a couple of chanegs that I'd like rolled in.
>> I've mentioned these before, though I've not gotten any response.
>> I understand we're all busy and don't have time to chatter, but
>> there are some
>> changes that would be beneficial to those of us who rather not
>> change the base source.
>> (I'm not critisizing, just trying to contribute)
> That's OK, we appreciate the contributes and criticisms. Sometimes a
> feature isn't in a component because we wrote something we needed,
> and we didn't need a particular feature that is entirely obvious for
> a different use case.

I do understand that, that is the way we work to.

>> 1) In-Mem spatial Index, I posted the to some people already.
> I am interested in seeing what the difference is between yours and
> the one in the toolkit.

The only one in the toolkit i saw was
This one is based of that one, but it will index an arbitrary
The reasong I created it was that I was using EsriPligin.
It ignores the shx, (which is reasonable if you're loading over the net)
so it painted everything, even the offscreen stuff.
Given the size of our datasets, that made it unusable.
The Spatial Index is just a linear search(not even ordered), but it does
wonders for the redraw...
It's pretty quick to "index" and performs OK on search
I tried the same approach with an R* tree implementation, but the
creation time was horrendus.

> 2) Object labler/formatter class. ( I have one for Shape labler )
> Sure, sounds interesting.

OK... We've been using this approach for years with our DB GUI
UnitHandler is a LocationLayer

>> 3) Tracing Labels for polylines(only on shape files) that hides
>> lables that are labeling object too mall)
>> Here I could use access the calculated text/font metrics etc.
> I think you can get that stuff from an OMText, no? Interesting idea
> for the tracing label, how does it affect performance (memory usage
> and generation)?

It would be available but not until after the setLocation() call.
I could not figure out the correct sequence of events, so I just used a
static for the min size.
The performance is fine (when I don't have to draw all the off-screen

>> (Would be very handy, some of the shape files I have are in the
>> 1/2-1 Gig range(200MB shape, 800MB dbf).

> 4) Filter on the Shape dbf stream to eliminate the columns we're not
> intrested in.
> This one is interesting and needed, too.
> They all sound like good improvements, please go ahead and mail in
> what you'd like to contribute.

Just give me free reins and the latest copy of the files and I'll do it.

> Regards,
> Don
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Don Dietrick,
> BBN Technologies, Cambridge, MA
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

[To unsubscribe to this list send an email to ""
with the following text in the BODY of the message "unsubscribe openmap-users"]
Received on Wed Feb 07 2007 - 19:13:00 EST

This archive was generated by hypermail 2.3.0 : Tue Mar 28 2017 - 23:25:08 EDT