2015-07-02 23:12 GMT+02:00 Paul Hartmann <[email protected]>: > On 02.07.2015 21:47, Wiktor Niesiobedzki wrote: >> >> Currently I'm working on WMTS support. As some of you may know (and >> those who do not, I refer to >> http://www.opengeospatial.org/standards/wmts) uses notion of >> scaleDenominator that's crucial to tile positioning. More less - >> scaleDenominator tell how many meters are on the tile per pixel. >> I tried several of algorithms to get the number of meters along >> meridian for current JOSM projection, > > > This value is not constant along a meridian, but depends on the latitude > (and sometimes longitude). Also, the value in east direction can be > different from the value in north direction (e.g. in WGS84). > >> [...] > > What you get here is not metersPerDegree, but metersPerNorthing. As far as I > know, this is the only way to find that number (but you have to plug in the > actual location). I've implemented this for the Piclayer plugin: > <https://trac.openstreetmap.org/browser/subversion/applications/editors/josm/plugins/piclayer/src/org/openstreetmap/josm/plugins/piclayer/layer/PicLayerAbstract.java#L304> > Anyhow, I'm pretty sure you don't need this for a WMTS implementation.
I understand, that how much real meters you get per unit of latitude as well as per unit of longitude differs for different part of the ellipsoid/sphere. But that's not what WMTS specification ask. The crucial part of spec says: pixelSpan = scaleDenominator × 0.28e-03 / metersPerUnit(crs); tileSpanX = tileWidth × pixelSpan; tileSpanY = tileHeight × pixelSpan tileMatrixMaxX = tileMatrixMinX + tileSpanX × matrixWidth; tileMatrixMinY = tileMatrixMaxY - tileSpanY × matrixHeight; And uses following wording: "the coefficient to convert the coordinate reference system (CRS) units into meters (metersPerUnit)" And metersPerUnit(crs) function is something I do need for proper computations. As I said, if I use the constant, I get working WMTS layer for WGS84 (no matter at which longitude and latitude), as well as for Mercator and PUWG1992. This is also the way OpenLayers implement their support for WMTS. >> Do I understand correctly, that for base projections: >> - org.openstreetmap.josm.data.projection.proj.LonLat - I should use >> degrees >> - org.openstreetmap.josm.data.projection.proj.Mercator - I should use >> meters >> - org.openstreetmap.josm.data.projection.proj.TransverseMercator - I >> should use meters > > > There is no reason to switch to other units as this is only an internal > number and not exposed to the user. The unit is arbitrary, so you can just > stick to meters. But there are some EPGS projections, that use other units internally (foot for example; EPGS:26782 and EPGS:3739 to use the ones shown in OpenLayers testcases). The question is: 1. Should I implement this as a part of Projection (I think this is preferred way, though the name "metersPerUnit" is misleading, though even OGC uses such name, so I would keep this with disclaimer) 2. Should I implement this as a part of WMTS tile source internal conversions, but then I would need to create my own dictionary of projections and which units internally do they use. Cheers, Wiktor _______________________________________________ josm-dev mailing list [email protected] https://lists.openstreetmap.org/listinfo/josm-dev
