Fix axis order for urn:ogc:def:crs:EPSG::4269 in crs-definition (#1962)

[vog]

Reference:

http://www.epsg-registry.org/report.htm?type=selection&entity=urn:ogc:def:crs:EPSG::4326&reportDetail=long&style=urn:uuid:report-style:default-with-urn&style_name=OGP%20Default%20With%20Urn&title=

[tfr42]

The deegree way of dealing with axis-awareness is to split the CRS definition into a not axis-aware part (backward compatible) using short ID and a axis-aware definition with the urn-id. Please check https://github.com/deegree/deegree3/wiki/Axis-order-handling.
See for example "epsg:31468" and http://www.opengis.net/gml/srs/epsg.xml#31468 where the crs definition is split.

[vog]

Unfortunately, my time is very constrained, so I won't be able to volunteer into the desired refactoring of the XML files.

If no other volunteer appears, I strongly recommend to include the bugfix now and doing the refactoring later.

[tfr42]

@vog Thank you for your contribution. Unfortunately, we need more background information before we can merge this PR. Can you provide more information about the use case?

[github-actions]

Thank you for your contribution. Unfortunately, this PR has been inactive for 90 days (see PR stuck workflow). Of course this is not the final word. The PR can become unstuck, for example, by reengaging in the discussion, answering open questions, rebasing, or adding new commits to this PR.

[vog]

Regarding the background information, the only thing I can say is that back in 2017, we noticed that deegree applied the wrong axis order to AIXM datasets that contained geometries declared as "urn:ogc:def:crs:EPSG::4326", and that the changed of this PR fixed this issue for us.