Jody Garnett ha scritto: >> If the data is in a 3D crs all of those will fail miserabily, meaning >> that it's not even possible to setup a 3d feature type in GeoServer >> (the lat/lon bbox computation will fail). > I do find it surprising that the these transformations are failing; I > thought that was the point of > having a real CRS around; allowing users to set up a transformation to > fit their assumptions > (rather than simply hacking of axis by hand).
May be... thought in fact changing datum projection is one thing, shaving off data in order to jump from a 3d to a 2d crs is another one. Yet, it can conceivably be done. What you cannot do is the opposite (2d -> 3d) unless you provide some sort of default for the extra dimensions in the destination. >> But that's not all, even when the new FORCE_2D hint is applied, to >> allow flattened data to be reprojected we need to associate the >> data to a 2D srs (hence my question). > Andrea perhaps we are working too hard here? The GML code is very > specific about its treatment of > coordinates; it really is just taking the first two ordinates right now > (and is not consulting the CRS at all). If > I match its assumptions we can just make a new CRS by hacking off the > last axis (ie the one matching > Coordinate.z). It's not that we're working too hard, we just have different objectives. When I say "3d integration" I mean more than just having GML2 output working, I also want wfs 1.1 (thus reprojection) and wms (again, reprojection in the mix) and finally wfs-t (ok, that's even harder, we're ok to have thing working read only). > Gak...perhaps we should look at CoordinateWriter a bit more. You're concentrating on a detail, I'm looking at the big picture. If you cannot compute the 2d bbox of the data in 4326 you cannot even configure them in GeoServer. There's more to having a WFS 1.0 working, even read only, than just writing the 3rd coordinate. For example, people can build up filters whose spatial component is in another crs, and we have code to reproject that back to the native crs before making the query to the datastore (since datastores are able to work only in their native crs query wise). But if the crs is 3d, hell, this makes thing a lot harder, we have to reproject the geometries in the filter to a 2d version of it and then have the datastore handle somehow the fact that the spatial filtering geometry is flat and the data is not... (for the record, building OGC filters with bbox or geometries in another CRS has always been in the spec, but we started supporting it only in 1.6.0, before GeoServer dully ignored the srs specification attached to the geometries in ogc filters). Cheers Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
