Hi, Got it!
You're both right that using URN:DEF will override the forceXY pattern. My problem had more to it than that. In some way I had both gt-epsg-wkt and gt-epsg-hsql at the class path. For my specific projection EPSG:3006, they are using a mix of axis orientation. Gt-epsg-hsql being the right one with north/east. I see there are some priority being used that will choose gt-epsg-hsql over gt-epsg-wkt. Because of the forceXY gt-epsg-hsql is removed from the list of factories, but not gt-epsg-wkt. In DefaultAuthorityFactory there is code to add factories to accommodate the urn:def pattern. This code loops through all factories regardless of the forceXY, but filter them according to the authority. Since gt-epsg-wkt and gt-epsg-hsql have the same authority, gt-epsg-hsql is skipped. And I would also believe that the final list of factories will not respect the priority. Why is gt-epsg-hsql removed in the first round and not gt-epsg-wkt? Wouldn't it be preferable to loop through the list of all factories once, and instead move those respecting forceXY forward? Best regards, Roar Brænden > 31. jan. 2022 kl. 15:22 skrev Jody Garnett <jody.garn...@gmail.com>: > > I that is a problem for the WMS code also (needing to ensure the coordinate > reference system matches the external system). > > You can use the full urn syntax to get the EPSG database order (ignoring > forceXY during lookup). > > Check the WMS client code for 1.3.0. > > Jody > > On Mon, Jan 31, 2022 at 12:21 AM Roar Brænden <roar.brenden...@gmail.com > <mailto:roar.brenden...@gmail.com>> wrote: > Hi Jody, > > Thanks for the reply. > > I've had a certain interest in WMTS lately, and also in gt-tile-client. I see > some clear benefits in clarifying the similarities between those two > projects. So that we at a later stage can introduce new functionality. Those > goes more in the direction of geowebcache. > I have looked at geopackage as well, but that is more for vector storage. > > At the moment I'm struggling with the projections part, and then particularly > forceXY. The problem is that if that system environment is set, it influences > the handling of CRS even if we don't want to. When the external capabilities > have boundingBoxes with latitude/longitude it goes wrong. What would the best > practice be? > - Warn the user that he is using forceXY, and that it will cause some trouble. > - Programmatically make sure that forceXY isn't used when dealing with > external boundingBoxes. > > If the latter. How do we do that? I've seen many approaches, but they doesn't > seem to handle everything. > > Best regards, > > Roar Brænden > > >> 30. jan. 2022 kl. 22:32 skrev Jody Garnett <jody.garn...@gmail.com >> <mailto:jody.garn...@gmail.com>>: >> >> First up thank you for the work, I spotted a couple documentation examples >> that needed to change headers, but Ian merged before my review was done. >> >> I recently looked at the geopackage module which also has a concept of tiles >> sets and projections (and defines some data structure along these lines). >> While the geopackage data structure is public it is not widely used; so if >> their is an opportunity to combine forces it would be good. >> >> GeoServer for the most part borrows data structure for grid sets from >> geowebcache; making for some duplication. >> >> Jody >> >> On Wed, Jan 26, 2022 at 12:25 AM Roar Brænden <roar.brenden...@gmail.com >> <mailto:roar.brenden...@gmail.com>> wrote: >> Hi, >> >> For the last year I've been working with the gt-wmts module. I've tried to >> clarify the responsibilties between WebMapTileServer and WMTSTileService. >> The first one building on OGC web service modules, and gimmick the WMTS >> standard. While the other one WMTSTileServer representing a single WMST >> matrix set, and using the functionality of gt-tile-client. >> >> Now I've written the documentation for my work. Which is in this PR >> <https://github.com/geotools/geotools/pull/3750>. >> >> >> While working with that documentation I discovered that we still have some >> problems with WMTS and projections. There were some work lately to handle >> that, but it seems to have missed some particularities. I would like to >> investigate that, but I do also have another PR >> <https://github.com/geotools/geotools/pull/3722> I would see in the code >> base before diving into my investigations. >> >> Could anyone be so kind to have a look at my work? >> >> Best regards, >> >> Roar Brænden >> _______________________________________________ >> GeoTools-Devel mailing list >> GeoTools-Devel@lists.sourceforge.net >> <mailto:GeoTools-Devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> <https://lists.sourceforge.net/lists/listinfo/geotools-devel> >> -- >> -- >> Jody Garnett > > -- > -- > Jody Garnett
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
