Hi Andrea, I don't know how you are progressing with the patch for 3D Geometry support. The cause of why I needed to investigate this issue has been resolved.
See the email discussion [1] concerning the geometry_column table becoming a geometry_column view in postgis v2.0. It may be worth your while to read the manual to see if any other changes may be of concern. [1] http://sourceforge.net/mailarchive/forum.php?thread_name=4B95BC7335A13A42AD0D23462F91AE6F616286349A%40echo.geometryit.com&forum_name=geotools-devel -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Andrea Aime Sent: Monday, 4 June 2012 10:32 PM To: Brett Walker Cc: [email protected] Subject: Re: [Geotools-devel] PostgreSQL/PostGIS and 3D Geometries On Mon, Jun 4, 2012 at 12:05 PM, Brett Walker <[email protected]> wrote: > >> > I see in BasicSQLDialect that you look into the z of teh >> geometry to determine the dimension, >> > imho this should be done the other way, just like we do with >> srid: a geometry is saved as >> > 3d if the database accepts 3d data, not the other way around. >> > If a 2d geometry is saved in a 3d database it must get in without >> issues. >> > Vice versa is indeed debatable, in my patch I forced 3d geoms to >> 2d if the database says so, silently, >> > but it's mostly a convenience (though I believe I prefer this >> behavior rather than an exception, >> > the data might be coming out of a processing chain that left >> some 3d bits in a data that is meant >> > to be saved as 2d, if we throw exceptions the caller will be >> forced to manually shave >> > off the third dimension). >> >> 2D into 3D I would call an error. Setting the third dimension to NaN >> is forcing a projection/transformation >> onto the data. A simple, trivial and naive >> projection/transformation, but the intent of the table may be >> violated by this. This assumption, I feel, may cause hidden problems. >> >> 3D into 2D I would also call an error for the same reason. >> >> Eh, I disagree strongly on this one, 2D into 3D is a case in which >> one should never throw an exception to me, >> and out of line with the default GeoTools behavior, which tries to >> adapt towards the target type (try to insert a linestring >> into a multilinstring attribute, or a string "1234" into a integer >> attribute, and you'll see, there are converters in place >> that transform data towards the expected type). > > If 2D to 3D causes no error and 3D to 2D causing an error; then the > following scenario would cause an error that is really out of place. I was thinking of it as a number conversion, int to float (less expressive into more expressive, 2d into 3d) is warranted without any intervention in programming languages, the opposite normally requires some extra (an explicit cast). But I agree the asymmetry is problematic. In fact the way I implemented it you would get no error in either direction. > > A user inserts a 2D into a 3D that is fine. The 2D geometry is coerced > into a 3D storage facility. The facility could be a DB, a shapefile or some > other facility. There is no error here given teh scenario. > > Then the user retrieves the shape from the storage facility. The > scenario would dictate that an error would occur. The user might raise an > eyebrow at this. I cannot get my data back out. > > I have mentioned shapefiles. What does the shapefile standard say > here? The the standard tight enough to cause an error or is the individual > features in a shapefile largely independant. I'm not knowledgable about > shapefiles. Shapefiles are similar to databases, but the presence of a Z is part of the geometry type definition, here is the full list: Null Shape Point PolyLine Polygon MultiPoint PointZ PolyLineZ PolygonZ MultiPointZ PointM PolyLineM PolygonM MultiPointM MultiPatch The conversions I did mention previously happen the moment you stick the data into a feature, they are data store independent, by the way they work they do happen both as you create features for insertion and as features are read from the store. This one we're discussing would be data store specific, but in line with the usual GeoTools behavior of converting instead Cheers Andrea -- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ GeoTools-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
