[Mapserver-dev] Shape bounds

Daniel Morissette morissette at dmsolutions.ca
Mon Nov 17 11:17:33 EST 2003


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
> 





More information about the mapserver-dev mailing list