[Mapserver-dev] Shape bounds

[Steve Lime]

For what it's worth I'm sticking with #2. The number of functions
producing shapes is limited and in some cases I guess may not even be
using the msAddLine function.

Steve

>>> Daniel Morissette <morissette at dmsolutions.ca> 11/17/2003 10:17:33
AM >>>
Um... tough call. Either way is good with me as long as the behavior is

clearly documented somewhere. With #2 one of the benefits (maybe the 
only one) is that when reading shapes from a file you can use the
bounds 
from the file and don't need to compute them. Other than that you
always 
end up computing the bounds anyway and the performance hit is the same

whether you do it on the fly or only at the end.

Daniel


Steve Lime wrote:
> There's a macro to test a box. The problem is more often the bbox is
out
> of sync with
> the coordinates. Maintaining the flag becomes the same issue as
> maintaining the bbox 
> itself. I'd like to simply agree that if a function/method builds a
> shape it has the responsibility
> to make sure the shape is complete. The code I wrote to build a
label
> outline is an example
> of such a function- and it doesn't rebuild the bbox.
> 
> Steve
> 
> 
>>>>Alan Steremberg <alans at wunderground.com> 11/13/2003 11:23:36 AM
>>>>
> 
> 
> Can you set a flag as to whether there is a valid bounding box?  That

> might make it all a bit easier to deal with..
> 
> Alan
> 
> On Thu, 13 Nov 2003 8:11am, Steve Lime wrote:
> 
>>Hi Folks:  Looking for opinions. In mapprimative.c lives a function
>>msAddLine that is the primary code for building shapes other than
>>reading directly from shapefiles. That code does not maintain a
> 
> shape
> 
>>bounding box. So should the bounding box be maintained:
>>
>>  1) withing msAddLine
>>  2) by the code making repetitive calls to msAddLine
>>
>>Ultimately I just want to make sure that an accurate bounding box is
>>available.  Option 1 centralizes the responsibility, but option 2 is
>>better for performance. After all, why set a bounding box until the 
>>full
>>shape is done. I'm leaning towards 2 and just fixing on part of the
>>label cache code.
>>
>>steve
>>
>>Stephen Lime
>>Data & Applications Manager
>>
>>Minnesota DNR
>>500 Lafayette Road
>>St. Paul, MN 55155
>>651-297-2937
>>_______________________________________________
>>Mapserver-dev mailing list
>>Mapserver-dev at lists.gis.umn.edu 
>>http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev 
> 
> --
> Alan Steremberg
> _______________________________________________
> Mapserver-dev mailing list
> Mapserver-dev at lists.gis.umn.edu 
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev 
> 


_______________________________________________
Mapserver-dev mailing list
Mapserver-dev at lists.gis.umn.edu 
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev