Although they should be optional with TMS 2.0, it could still be useful to define WKSS' for our TMS specs. These would need 1:1 naming matching with the TMS specs and any changes from #19.
The problem I am having so far however is that I can only find examples of the actual contents from the specs in html layouts like at the first link below. I can probably infer what it would look like in json or xml, but I am a bit confused why I can't actually find the xml and json representation of existing wkss laying around anywhere (opengist.net is no help weirdly). As both the scale denominator and pixel size are columns in the TMS spec it should be just a matter of copying those attributes, I just can't find an example.
note: after looking at GDAL's code, it maybe that these WKSS string may just need to be set to a string but that the drivers never actually use it. However older clients may still use these so it is unknown if they are truly needed or not
Although they should be optional with TMS 2.0, it could still be useful to define WKSS' for our TMS specs. These would need 1:1 naming matching with the TMS specs and any changes from #19.
The problem I am having so far however is that I can only find examples of the actual contents from the specs in html layouts like at the first link below. I can probably infer what it would look like in json or xml, but I am a bit confused why I can't actually find the xml and json representation of existing wkss laying around anywhere (opengist.net is no help weirdly). As both the scale denominator and pixel size are columns in the TMS spec it should be just a matter of copying those attributes, I just can't find an example.
note: after looking at GDAL's code, it maybe that these WKSS string may just need to be set to a string but that the drivers never actually use it. However older clients may still use these so it is unknown if they are truly needed or not
links: