I'd also like to draw to the community's attention the second part: geometries that are referenced to the curve, that is, engineering coordinates that refer to down-hole distance. These are are a one-dimensional geometry defined only in the context of that borehole, and the usual way that bore down-hole data is referenced (whether by down-hole instruments or core loggers).
What support do we have for such engineering CRS? On 03/08/10 11:39, v...@csiro wrote: > > what are the thoughts of the community on support for 3D coordinates? > > This is an issue raised by a geologist > > I'm trying to figure out if GeoServer can deliver a series of > LineStringSegment coordinates (x,y,z) to represent a complex 3D Curve > geometry. > Let's imagine for a second that geologists would like to deliver Borehole > information (this is pure speculation of course) they first have to be able > to deliver borehole geometries in 3D... yes, recent scientific > investigations support the crazy hypothesis that the Earth isn't flat! I > know, it sounds crazy... > > This is what one will expect to find in the WFS response returned by > Geoserver (with correct coordinates URI this time): > > > <?xml version="1.0" encoding="UTF-8"?> > <wfs:FeatureCollection numberOfFeatures="1" > timeStamp="2010-05-06T13:35:59.296+10:00" > xsi:schemaLocation="urn:cgi:xmlns:CGI:GeoSciML:2.0 > http://www.geosciml.org/geosciml/2.0/xsd/geosciml.xsd > http://www.opengis.net/wfs > /Users/duc025/dev/GeoServer_Schema/wfs/1.1.0/wfs.xsd" > xmlns:ogc="http://www.opengis.net/ogc"; > xmlns:sa="http://www.opengis.net/sampling/1.0"; > xmlns:om="http://www.opengis.net/om/1.0"; > xmlns:wfs="http://www.opengis.net/wfs"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xmlns:gsml="urn:cgi:xmlns:CGI:GeoSciML:2.0" > xmlns:ows="http://www.opengis.net/ows"; > xmlns:gml="http://www.opengis.net/gml"; > xmlns:xlink="http://www.w3.org/1999/xlink";> > <gml:featureMembers> > <gsml:Borehole gml:id="Hypothetical3DBorehole1"> > <gml:name > codeSpace="http://nvclwebservices.vm.csiro.au/geoserverBH/wfs"; > >Hypothetical3DBorehole1</gml:name> > <sa:sampledFeature > xlink:role="http://www.geosciml.org/geosciml/2.0/doc/GeoSciML/GeologicUnit/GeologicUnit.html"; > xlink:href="http://www.opengis.net/def/nil/OGC/0/unknown"/> > <sa:shape> > <gml:Curve> > <gml:segments> > <gml:LineStringSegment> > <gml:posList srsDimension="3" > srsName="http://www.opengis.net/def/crs/EPSG/0/4939";>-25.0 119.0 0 -25.0 > 119.01 23</gml:posList> > </gml:LineStringSegment> > <gml:LineStringSegment> > <gml:posList srsDimension="3" > srsName="http://www.opengis.net/def/crs/EPSG/0/4939";>-25.0 119.01 23 -25.013 > 119.012 73</gml:posList> > </gml:LineStringSegment> > <gml:LineStringSegment> > <gml:posList srsDimension="3" > srsName="http://www.opengis.net/def/crs/EPSG/0/4939";>-25.013 119.012 73 > -25.014 119.014 111</gml:posList> > </gml:LineStringSegment> > </gml:segments> > </gml:Curve> > </sa:shape> > <gsml:collarLocation> > <gsml:BoreholeCollar > gml:id="BoreholeCollarID_BOREHOLE.UDD1420"> > <gsml:location> > <gml:Point srsDimension="2" > srsName="http://www.opengis.net/def/crs/EPSG/0/4283";> > <gml:pos>-25.0 119.0</gml:pos> > </gml:Point> > </gsml:location> > <gsml:elevation srsDimension="1" > srsName="http://www.opengis.net/def/crs/EPSG/0/5711";>210.0</gsml:elevation> > </gsml:BoreholeCollar> > </gsml:collarLocation> > </gsml:Borehole> > </gml:featureMembers> > </wfs:FeatureCollection> > > > This is the kind of data that the geologists will store in their database: a > 'typical'Borehole Survey file: > > HOLEID DEPTH AZIMUTH DIP > 3DBorehole1 0 90 -73 > 3DBorehole1 23 123 -63 > 3DBorehole1 73 114 -59 > > The 3D coordinates of the Borehole is given in the BoreholeCollar Feature > gsml:location (x,y) and gsml:elevation (z), then the DB need to have a table > that recomputes the (x,y,z) of each LineSegment based on the Borehole Survey > data. -- Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au> Software Engineering Team Leader CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
