Opened 13 years ago
Closed 13 years ago
#3906 closed enhancement (fixed)
add 2.5d support to OGR output
| Reported by: | msmitherdc | Owned by: | warmerdam |
|---|---|---|---|
| Priority: | normal | Milestone: | 6.2 release |
| Component: | OGR Support | Version: | svn-trunk (development) |
| Severity: | normal | Keywords: | wfs, 2.5d, Z, ogr, output |
| Cc: | dmorissette |
Description
There is a need for Z values in OGR Output formats generated by mapserver
Attachments (5)
Change History (18)
by , 13 years ago
| Attachment: | testshape_3d.zip added |
|---|
by , 13 years ago
| Attachment: | testshape_3d.map added |
|---|
comment:3 by , 13 years ago
Nevermind on output projection. This is easily done in WFS 1.1 with SRSNAME
comment:4 by , 13 years ago
bump,
Ideally two things need to be done.
1) add optional support when build with enable_z_m to capture Z coordinates and output them if they are available.
2) when there isn't z we should only generate 2D geometries which could be accomplished by post-flattening the geometries just before they are written out.
comment:5 by , 13 years ago
I would just caution against using OGR_G_SetPoint_2D() which is a relatively new addition to OGR and would incorporate an unnecessary version dependence. Thus the suggestion of OGR_G_FlattenTo2D() which I think has been available for a long time.
comment:6 by , 13 years ago
| Cc: | added; removed |
|---|---|
| Owner: | changed from to |
I'm seizing this, and going to take a crack at it tonight.
comment:7 by , 13 years ago
comment:8 by , 13 years ago
| Status: | new → assigned |
|---|
Mike,
My problem last night turn out to be a failure to build WFS server support in!
Working on linux now...
comment:9 by , 13 years ago
Mike,
On brief inspection your .shp file does not seem to have any non-zero Z values despite having a geometry type for 2.5D features.
It looks like the OGR reader in MapServer does not collect Z values even when USE_POINT_Z_M is set, so I'm going to need to fix that up as well as mapogroutput.c. I have a preliminary patch for mapogroutput.c but it is hard to fully test with the data at hand.
comment:10 by , 13 years ago
Frank,
Correct, its really a 3d shapefile. The issue i was getting is that I'm receiving 0's rather the Z values with x,y,z are present and (for some drivers like geojson) getting 0's for z when its just X and Y input.
To see the Z output from 2d with the new mapfile and data layer
comment:11 by , 13 years ago
Mike,
I have confirmed and corrected the issue of always producing Z=0 values even if the input and desired output is 2D. But since there are no non-zero Z values in the sample file I'll need to dig up some other data and an alternate test to confirm we can pass through non-zero Z's properly.
comment:12 by , 13 years ago
The first test file should have non-zero Z values. But if thats not what you need, let me know and I can generate whatever you need to test.
comment:13 by , 13 years ago
| Milestone: | 6.0.1 release → 6.2 release |
|---|---|
| Resolution: | → fixed |
| Status: | assigned → closed |
Mike,
I have adjusted mapogroutput.c to:
1) Determine what geometry type to create the output layer based on whether the _geomtype metadata has 25D appended or not. So to produce 2.5D output you would use "ows_geomtype" "MultiLineString?25D".
2) In USE_POINT_Z_M mode the Z will actually be carried through properly now.
These changes are in trunk (r12022). I have also updated the msautotest suite (r12023) so that it does not expect the Z values for the existing test cases though I have not extended the test suite with 2.5D cases.
It should be noted that only the builtin shapefile driver and oracle drivers carry through Z in USE_POINT_Z_M mode. The PostGIS and OGR drivers do not. It might be worthwhile to extend them.
Docs have been extended to mention 2.5D geomtype values (r12024).
If you need this backported into the 6.0 stable branch let me know. I don't think it would be dangerous.
mapfile for testcase