Hi Justin, Andrea, Nuno, Regarding the FEATURE_2D hint:
1) The default behavior of any reader should be to return the data as it is stored. If the data is 3D, 3D data is returned. If the data is 2D, 2D data is returned, for every kind of data store. 2) The FEATURE_2D hint should be used to change this default behavior. So, if FEATURE_2D is set (FEATURE_2D exists and FEATURE_2D=True), then 2D data should be returned. 3) If FEATURE_2D is not defined or FEATURE_2D=False, the the default behavior apply, ie return data as it is stored. 4) I think we should find out if there is any code breaking if PostGIS data is returned in 3D, when no Hint is defined. If the code is breaking, we should fixed it, so the behavior is always the same for every kind of data store: if no FEATURE_2D hint is defined, data is returned "as is". So, IMHO the encodeGeometryColumn should also return 3D data for PostGIS data sources, even when the FEATURE_2D hint is not defined. Comments are welcome, because I might be forgetting some other implications. Jorge Em 04-05-2012 13:03, Andrea Aime escreveu: > On Fri, May 4, 2012 at 12:44 AM, Justin Deoliveira <[email protected] > <mailto:[email protected]>> wrote: > > Hi Nuno, > > No problem about the misformatting, it is a very common thing for > people contributing initial patches. The new patch looks much nicer, > thanks! > > So, its looking good for the most part. Although it looks like 3d is > only respected if the 2d hint is specified to be false. I think it > should be respected if the 2d hint is false, or the 2d hint is not > specified at all. > > Also one thing is that we need to deprecate the old > SQLDialect.encodeColumnName method, and probably have the > implementation call through to the new one. > > As for the test i think it looks good, although with the behavior i > mentioned above about interpreting the 2d hint it should no longer > be necessary to override any of hte test methods in Postgis3D test. > > > Hum, > the original intended behavior for the hint was to return 3D geometries > any time the hint was not explicitly > set, that's how we got 3d geometries in GML and KML output even if those > do not explicitly set any hints, > while on the other side the renderer manually forces the hint in. > > Do you know of other code paths, besides the renderer, that would break > when facing 3D data? > > 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/ > > > > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- Jorge Gustavo Rocha Departamento de Informática Universidade do Minho 4710-057 Braga Tel: +351 253604480 Fax: +351 253604471 Móvel: +351 910333888 skype: nabocudnosor ------------------------------------------------------------------------------ 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/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
