RE: [OpenMap Users] MIFLoader & OMSubtraction

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?

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

Thanks

Simon
-----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"]