refactor geographic crs attribute

[vincentsarago]

ref #157 #152

what do you think @AndrewAnnex

#152 introduced the fact the _geographic_crs could be stored in the TMS document but that is breaking the TMS specification.

if the proposed solution (relying on crs.geodetic_crs) doesn't work, then I'm not sure what we should do

[AndrewAnnex]

@vincentsarago yeah I was having to store _geographic_crs because it was getting set to WGS84 by default, and #152 was in keeping with that to avoid breaking changes. I definitely want to get to a place where I am not doing that and the geographic crs get's correctly interpreted from the CRS of the TMS
I think this should work but there might be some weird cases where the axis order/coordinate system changes (like Mars planetographic with northing westing coordinates) and by explicitly setting a geographic_crs within the tms as a separate parameter you can work to avoid that. In any case, I think this is better than assuming 4326/wgs84. But in any case if it's breaking the specification that's something to work on fixing. I don't think the Spec says the geographic crs must be 4326 right?

[vincentsarago]

I don't think the Spec says the geographic crs must be 4326 right?

Yeah, the fact that we need the geographic CRS is strictly for morecantile internals:

morecantile/morecantile/models.py

Line 904 in 1829fe1

lng, lat = self._to_geographic.transform(x, y)

morecantile/morecantile/models.py

Lines 1177 to 1189 in 1829fe1

	@cached_property
	def bbox(self):
	"""Return TMS bounding box in geographic coordinate reference system."""
	left, bottom, right, top = self.xy_bbox
	return BoundingBox(
	*self._to_geographic.transform_bounds(
	left,
	bottom,
	right,
	top,
	densify_pts=21,
	)
	)

morecantile/morecantile/models.py

Lines 1328 to 1332 in 1829fe1

	if not projected:
	west, south, east, north = self._to_geographic.transform_bounds(
	west, south, east, north, densify_pts=21
	)

[vincentsarago]

for some TMS, the geographic_crs returned by tms._pyproj_crs.geodetic_crs isn't strictly equal to WGS84, but by checking the geographic transformation of the tms bbox we can see they give the same result

[vincentsarago]

@AndrewAnnex are we good here?

[AndrewAnnex]

@vincentsarago yeah I think this is looking good now, I don't think you need to do quite as much work in the tests with transforming the bboxes though as to and from geographic functions both enforce always_xy order, but think this is about right.

let's lift the test from my other pr into this pr and see if anything needs to be changed, or I can make a follow on PR:
https://github.com/developmentseed/morecantile/pull/157/files#diff-0adb667cd397bd56edce10eec11e1b10821740a10d72bd148b09645fc9108968R293

[vincentsarago]

let's merge this one and then you can create a new PR with the tests

[AndrewAnnex]

@vincentsarago something isn't quite right with TMS with inverted axes, I am investigating but will need to stop and do other things so unless I see a quick fix I'll push a pr with failing tests