Hello everyone,
Thanks for your comments. I suggest then that I implement the behaviour
as it was suggested in the example of WFS 2.0 specs, since this is also
the least invasive for the geotools/geoserver code, and there don't
appear to be any particular objections against it. I suggest also
On Mon, Oct 11, 2021 at 7:05 PM Niels Charlier wrote:
> Hello Andrea,
>
> I did not mean to misrepresent you. I actually thought your suggestion
> made sense. The new method in the CRS class is (currently) only intended
> for reprojection.
>
The CRS class is a generic facade to the capabilities
Hello Andrea,
I did not mean to misrepresent you. I actually thought your suggestion
made sense. The new method in the CRS class is (currently) only intended
for reprojection.
As far as the standard goes, I was referring to the ""OGC® Web Feature
Service 2.0 Interface Standard – With
On Mon, Oct 11, 2021 at 3:21 PM Niels Charlier via GeoTools-Devel <
geotools-devel@lists.sourceforge.net> wrote:
> 2) allow reprojection 3D->2D and only prevent 2D->3D reprojection
> (Andrea's suggestion).
Before this gets out of hand, my suggestion is limited to the CRS class
We had similar challenge when drawing WMS, if I remember we reproject to
wgs84 3D, drop the Elevation, and then reproject from wgs84 to the final 2d
projection.
That is our own assumption to draw 3D data, folks can use function calls as
part of their WFS query to get a similar result can they
Hello Jukka,
Thanks for your answer. I guess I wanted to ask the opinion of the
community on how to proceed. I see at this point two options:
1) stick with the suggestion of the standard, and do not project 3D->2D.
(The easiest solution, what I already have).
2) allow reprojection 3D->2D
