Re: [OpenMap Users] MIFLoader & OMSubtraction

Hi Simon,

That's awesome.

On Jan 26, 2004, at 11:19 AM, Simon Bowen wrote:

> Don,
>
> I am on the case of updating the mif package to improve the
> performance.
>
> I am also taking the opportunity to add some extra support for
> different primitives as the current package only supports PLINE and
> REGION MIF primitives.
>
> I have a question, I am going through the MIF specification from Map
> Info
> And some of the primitive definitions specify the size of the graphics
> in Points (just like font sizes), do you have any suggestions on how I
> can interpret this "Point" size into a value for say the radius
> parameter for the OMPoint constructor. And exactly what is the metric
> for the radius parameters? Is it degrees? Pixels? Radians?

It's pixels. If the file doesn't have any information on how the point
should be portrayed, I would let the pixel radius size for points be
set via a layer property, so the user would determine how big to make
it.
>
> I am hoping the get the modified MIF package to you toward the end of
> this week. Time allowing I should have
>
> 1. Increased the performance by 60-70%
> 2. Added support for (although limited) POINT, ARC, TEXT, RECT, ELLIPSE
> 3. I am hoping I can add support for MID files also, but hat will not
> be ready this week
>

That's great. We're going to be making the 4.6 release on Friday
afternoon, if I get your code we'll include it then, else we'll make a
quick update release in the next couple of weeks after that.

Thanks again,

Don

> -----Original Message-----
> From: Don Dietrick [mailto:dietrick@bbn.com]
> Sent: 23 January 2004 22:03
> To: Simon Bowen
> Cc: 'openmap-users@bbn.com'
> Subject: Re: [OpenMap Users] MIFLoader & OMSubtraction
>
> Hi Simon,
>
> I'm not sure what the original author had in mind with his algorithm,
> the MIF layer package was gratefully received from a contributor.  If
> you'd like to submit your improvements we'll certainly incorporate them
> into the code base.
>
> Regards,
>
> Don
>
> On Jan 23, 2004, at 10:41 AM, Simon Bowen wrote:
>
> > Hello,
> >
> >  
> >
> > I have been having serious performance problems with the MIF
> (MapInfo)
> > layer functionality of OpenMap, specifically noticeable when using
> > large MIF files (i.e. 10mb or above).
> >
> >  
> >
> > My initial thoughts on why this was lead me towards either the file
> > i/o or the actual tokenizing of the file to create the OMGraphics.
> >
> >  
> >
> > I attached a profiler to an OpenMap instance that was loading MIF
> > files and discovered that over 60% of the MIF processing of loading
> > and rendering a fresh MIF file was down to a function
> > com.bbn.openmap.layer.mif.OMSubtraction$SubArea.contains(..).
> >
> >  
> >
> > The contains function of OMSubstraction is called when the MIFLoader
> > is processing a REGION section of the MIF file, to determine if the
> > current region being processed is contained within another region
> that
> > has already been created, if so do not bother creating the graphic
> > just move onto the next section of the file.
> >
> >  
> >
> > Now what I have found is that the "contains" check is actually more
> > expensive to call than actually creating the OMGraphic.
> >
> >  
> >
> > I have now managed get loading of a 44MB mif file down by about 63%.
> >
> >  
> >
> > Is there any specific reason for the
> OMSubtraction.$SubArea.contains()
> > call that I have overseen?? I have tried with my test data and cannot
> > see a difference in functionality and only an increase in
> performance.
> >
> >  
> >
> > Any expert advice in this area of the OpenMap framework will be
> > greatly appreciated.
> >
> >  
> >
> > Thanks
> >
> >  
> >
> > Simon
> >
> >  
>
> --
> [To unsubscribe to this list send an email to "majdart@bbn.com"
> with the following text in the BODY of the message "unsubscribe
> openmap-users"]

--
[To unsubscribe to this list send an email to "majdart@bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]