Opened 17 years ago
Closed 17 years ago
#226 closed defect (fixed)
Buffer is not Accurate
Reported by: | cgountanis | Owned by: | |
---|---|---|---|
Priority: | high | Milestone: | 2.0 |
Component: | Viewer Command | Version: | 1.2.0 |
Severity: | major | Keywords: | buffer |
Cc: | External ID: |
Description
Seems when you do buffers the end result is 3 times smaller than it should be. 33 feet barely gets you into a road. 33 meters gets you across the road. Is there a solution to this mis-calculation. If a customer does 100 feet buffer and it only shows about 30 we have an issue correct?
Change History (6)
comment:1 by , 17 years ago
Keywords: | buffer added |
---|---|
Milestone: | → 1.3 |
Version: | → 1.2.0 |
comment:2 by , 17 years ago
Hi Chris, please add steps to reproduce. If you can attach a package and web pages that a developer could just drop in and quickly reproduce I think that someone can start looking into this immediately. Or, if the problem could be reproduced in Sheboygan, the steps to reproduce using that would be useful as well. Thanks Tom
comment:3 by , 17 years ago
Sure, we have found no matter what site you ise the issue is there.
http://data.mapguide.com/mapguide/gt/index.php for example. Select a Parcel near a road and do a 30-35 foot buffer. Notice the buffer does not even make it to the center point of the roads. We are talking 30 foot roads max you know? Very easy to reproduce. Please let me know if you get mixed results becasue it seems clear to us and our customers. Seems it does this on stateplane, xy doen't matter they all are short.
comment:4 by , 17 years ago
Still missing steps to recreate... these should probably do...
1) Go to the above web site 2) Download the sample code and package from the main page, and install 3) Zoom in to about 1:1000 (click on the status bar scale indicator to put it into edit mode, and enter 1000) 4) Select one of the beige polygons (parcel) 5) Start the buffer task and create a buffer of 30 feet 6) zoom in so that a part of the buffer mostly fills the screen Note from the dimensions of the screen (given by the map size part of the status bar) the size of the buffer is only about 10 feet.
Also note that the buffer seems to be correct with Sheboygan which is LL if I recall correctly. Not sure what the above example is in.
comment:5 by , 17 years ago
Same issues with me...What Units does Buffer Expect to be sent in? Starting with unit type of feet and distance of 100. Background: When I do a ->getunits on the Coordinate System (srsDs) it returns US_foot When I do a ->getunitScale on the Coordinate System (srsDs) it returns 0.304800609601
Earlier in the PHP code it converts my Units to Meters from feet: {if($units == "fe") feet $distance *= .30480;} Returning distance=30.480 Then later the Code does this: $dist = $srsDs->ConvertMetersToCoordinateSystemUnits($distance) returning dist=99.9998 After this it Creates $measure = new MgCoordinateSystemMeasure($srsDs);
Here's Where it gets weird if I run measure->getDistance(1.0,0.0,0.0,0.0) I would expect it to return the value of 1 but instead it returns 3.27654107864 (Shouldn't the Measure Object be in feet since it was created off a US Foot coordinate system or is it assuming Meters on coordinates sent in???) We Use Measure and dist to create the buffer so since a one unit coordinate change returns 3.27654107864 it makes sense why the distance would come up so much smaller. $geomBuffer = $geom->Buffer($dist, $measure);
Its somewhere in the MgCoordinateSystemMeasure area or in the 0.304800609601 UnitScale on the coordinate system...I know how to force a fix...but it wouldnt repair whats ultimately really broken here.
comment:6 by , 17 years ago
Component: | Drawing Service → Viewer Command |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Defect is no longer reproduceable as a result of changes made via implementation of RFC 35 - Coordinate System API Cleanup. Tested creation of 10 metre buffer, and also 33 feet buffer around a parcel adjacent to a road. Buffer region is virtually identical, extending out near the middle of the road. Zooming map such that visible region is about 35 feet across, nearly fills the screen with the buffer. See also ticket #278.
This is happening with StatePlane, X-Y with unit types Feet as default on the test\customer sites.