Opened 18 years ago
Closed 18 years ago
#1586 closed defect (fixed)
geometry and projection with WFS
Reported by: | assefa | Owned by: | mapserverbugs |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | WFS Server | Version: | 4.8 |
Severity: | normal | Keywords: | |
Cc: |
Description
initial problem reprorted by Tom : Hi, We're serving a WFS of data natively in EPSG:42304. We would like to serve as EPSG:4326. We have set MAP/WEB/METADATA/"wfs_srs" "EPSG:4326". When invoking a GetFeature request: http://devgeo.cciw.ca/cgi-bin/mapserv/kyw?VERSION=1.0.0&SERVICE=WFS&REQU EST=GetFeature&TYPENAME=canadwshed&Filter=<Filter><DWithin><PropertyName >>Geometry</PropertyName><gml:Point><gml:coordinates>-65.471193,45.429475 </gml:coordinates></gml:Point><Distance%20units='deg'>0</Distance></DWit hin></Filter>& ...the feature is provided in EPSG:4326 as set in the mapfile, however gml:featureMember/kyw:canadwshed/gml:boundedBy returns the bounded areas in the native coordinates. However, gml:featureMember/kyw:canadwshed/gml:boundedBy/gml:Box/@srsName returns EPSG:4326. Could it be that mapgml.c is not reprojecting the boundedBy coordinates at the layer level? It is doing so for the geometry of the feature, as well as the boundedBy of the response. ..Tom
Change History (7)
comment:2 by , 18 years ago
The bounds, I think, would be valid, as it's generated by some sort of minimim bounding rectangle call in the code? There's no reason NOT to reproject. OGC:WFS, by nature, supports only ONE projection. Whatever the projection is set to in MAP/WEB/METADATA/wfs_srs, all output geometries should come out in this projection.
comment:4 by , 18 years ago
Cc: | added |
---|
Frank, Daniel any objection for adding msProjectRect(in, out, &shape->bounds); in msProjectShape ? Kind of last minute ? 652c652,655 < return(MS_SUCCESS); --- > { > msProjectRect(in, out, &shape->bounds); > return(MS_SUCCESS); > }
comment:5 by , 18 years ago
Cc: | added |
---|
Reprojecting the bounds can lead to a box that's larger than it needs to be. I think it would be better to keep track of the new bounds as each vertex is reprojected... or maybe call msComputeBounds()... which might be slightly slower, but would be safer. Adding Steve to CC since I see calls to msComputeBounds() in the query code, so maybe the bounds are not expected to be valid at all times and it's mapgml.c that needs to compute them?
comment:6 by , 18 years ago
I would agree that it is much much safer to just recompute the bounds after the shape is reprojected, rather than depending on the rect reprojector. I would add that recomputing the bounds is a pretty safe operation to add, and so we could do it now before release.
comment:7 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Added code to recompute bounds after successful reprojection. Marking as fixed, but if Tom would please test... Steve
Note:
See TracTickets
for help on using tickets.