In Geo.py Transformation.untransform, on the input, it is expected (at least how ModestMaps is used by TileStache), that the input point coordinates are representing row and column of requested tile.
According to http://blog.kartena.se/local-projections-in-a-world-of-spherical-mercator/, cx and cy parameters are supposed to be Origin of the tile set, which is given in map units (meters in my case).
Therefore, the transform/untransform function can not work well, if cx and cy parameters are given in map units, because it's calculating with input rows/columns.
Either the code is wrong, or it's usage in TileStache or my understanding of Transformation (based on the blog mentioned earlier)
class Transformation:
...
# point uses coordinates representing columns/rows of given tile
# cx and cy are given in map units (meters) of the tile set origin - or maybe not?
def untransform(self, point):
return Point((point.x*self.by - point.y*self.bx - self.cx*self.by + self.cy*self.bx) / (self.ax*self.by - self.ay*self.bx),
(point.x*self.ay - point.y*self.ax - self.cx*self.ay + self.cy*self.ax) / (self.bx*self.ay - self.by*self.ax))
In Geo.py Transformation.untransform, on the input, it is expected (at least how ModestMaps is used by TileStache), that the input point coordinates are representing row and column of requested tile.
According to http://blog.kartena.se/local-projections-in-a-world-of-spherical-mercator/, cx and cy parameters are supposed to be Origin of the tile set, which is given in map units (meters in my case).
Therefore, the transform/untransform function can not work well, if cx and cy parameters are given in map units, because it's calculating with input rows/columns.
Either the code is wrong, or it's usage in TileStache or my understanding of Transformation (based on the blog mentioned earlier)