TMS support MapKnitter
Closed this issue · 24 comments
is it truly working? I believe I have a working MapProxy TMS that's not working with MapKnitter.
i believe it is - the example of it not working is due to a carriage return in the TMS url:
this needs better validation then, to prevent carriage returns:
tile_url: "http://mapproxy.slocountyfire.org/tms/1.0.0/slocounty-
12in/EPSG4326",
for now i'll fix it in the db
looks ok now... but the TMS isn't loading. Can you confirm that you have the right zoom levels?
Trying your TMS in Leaflet: http://archive.publiclaboratory.org/leaflet/?tms=http://mapproxy.slocountyfire.org/tms/1.0.0/slocounty-12in/EPSG4326&lat=35.3579336327&lon=-120.578004109&min=12&zoom=14
it doesn't look like you do...
anyhow this validation needs:
validates_format_of :domain_name, :with => /^(http|https):\/\/[a-z0-9]+([\-\.]{1}[a-z0-9]+)*\.[a-z]{2,5}(:[0-9]{1,5})?(\/.*)?$/ix
tried http://mapproxy.slocountyfire.org/tms/1.0.0/slocounty-12in_EPSG4326 and added a "/" to the end …both times watching Firebug…a period gets inserted. I think we have the right zoom levels (20) http://mapproxy.slocountyfire.org/demo/?tms_layer=slocounty-12in&format=png&srs=EPSG%3A4326
I can't test it at the moment, but might it have to do with the layername being . in public/knitter.js?
var tms = new OpenLayers.Layer.TMS( "OpenLayers TMS", Config.tile_url, {
//projection: latlon,
//displayProjection: spher_merc,
//getURL: Knitter.overlay_getTileURL,
//maxResolution:156543.0339,
//units: "m",
//maxExtent: new OpenLayers.Bounds(-20037508, -20037508, 20037508, 20037508.34),
//tileOrigin: new OpenLayers.LonLat(0,0).transform(latlon,spher_merc),
numZoomLevels: 22,
serviceVersion: '.',
layername: '.',
type: 'png',
alpha: true,
isBaseLayer: true});hmm, interesting. what is the layername you want? I can add a field for
layername with a strong default.
OpenLayers can be really cranky - if you want to debug, i might recommend
using the Leaflet install (view source at
http://archive.publiclaboratory.org/leaflet/) just to be sure it's not some
arcane OpenLayers issue stopping us. Once we confirm that the TMS is
responding well, we can debug OpenLayers.
Thanks for your patience on this! Not too many people use TMS layers so
it's not as maintained of a feature, but it's an important one.
On Tue, Apr 24, 2012 at 9:45 PM, Corey Farwell <
reply@reply.github.com
wrote:
I can't test it at the moment, but might it have to do with the layername
being '.' in public/knitter.js?var tms = new OpenLayers.Layer.TMS( "OpenLayers TMS", Config.tile_url, { //projection: latlon, //displayProjection: spher_merc, //getURL: Knitter.overlay_getTileURL, //maxResolution:156543.0339, //units: "m", //maxExtent: new OpenLayers.Bounds(-20037508, -20037508, 20037508, 20037508.34), //tileOrigin: new OpenLayers.LonLat(0,0).transform(latlon,spher_merc), numZoomLevels: 22, serviceVersion: '.', layername: '.', type: 'png', alpha: true, isBaseLayer: true});
Reply to this email directly or view it on GitHub:
#101 (comment)
Hate to keep beating away at this - but I feel it's really important that we explore the possibility of aligning against a more accurate basemap (with more zoom levels than Bing/Google). I believe @frewsxcv realized we may need this served in web mercator, so he setup 3857 on our mapproxy http://mapproxy.slocountyfire.org/tms/1.0.0/slocounty-12in/EPSG3857 <- you can see here that zooms 0-19 are served ... and it aligns with a 3857.shp for me in QGIS.
I cannot get other TMS URLs to serve in the PublicLab Leaflet http://archive.publiclaboratory.org/leaflet/?tms=http://hypercube.telascience.org/tilecache/tilecache.py/1.0.0/NewWorld_google&lat=35.3579336327&lon=-120.578004109&min=12&zoom=14 nor do the example TMSs work for me, that come built-in to the MapKnitter 'Choose background layer..' context.
No, thank you very much for helping to debug this -- i agree that TMS is important and want to do everything possible to get it working properly.
I get http://hypercube.telascience.org/tilecache/tilecache.py/1.0.0/NewWorld_google14/2705/9914.png for a requested TMS tile in the Leaflet link you posted. So at least initially the problem was from a missing trailing slash in the URL. But a corrected Leaflet URL also generates errors:
http://hypercube.telascience.org/tilecache/tilecache.py/1.0.0/NewWorld_google/15/5408/19826.png
I think this is due to the above "layer" name issue. The TMS ought to have a layer name, maybe "main". If you don't know the layer name, then if you can just send me the URL of a single working tile, I can figure it out.
I think we're almost past the "discovery/description" phase of debugging and then we can start talking about possible solutions. :-)
Oops, the error was for the hypercube TMS. I'll look up the layer name for that... in the meantime, here's the corresponding failing URL for the TMS you posted:
http://mapproxy.slocountyfire.org/tms/1.0.0/slocounty-12in/EPSG3857/14/2705/9914.png
Do you know the layername for that?
@jywarren thank you for staying with me on this! http://mapproxy.slocountyfire.org//tms/1.0.0/slocounty-12in_EPSG3857/9/133/155.png is a URL of a single working tile. I believe that slocounty-12in_EPSG3857 is the layer name in this situation.
I just tested a working TMS in both MapKnitter and Leaflet, and both seem to be reading the tiles correctly, although I suspect they may not have the same coordinate origins. But what makes it hard to see or test is that MapKnitter maps are typically at zoom levels 20-23, and almost no TMS sources (which work globally, anyways) offer that. So for many views, the TMS is erroring out because there is simply no tile data available at that zoom level.
I'm also using this utility to try swapping the origin coordinates to see if that's the issue: http://tmsfilter.publiclaboratory.org/
However if you can send over the URL of a tile, that should be enough to solve our problems.
Oh, great. checking now...
On Mon, May 14, 2012 at 1:42 PM, Joe Larson <
reply@reply.github.com
wrote:
@jywarren thank you for staying with me on this!
http://mapproxy.slocountyfire.org//tms/1.0.0/slocounty-12in_EPSG3857/9/133/155.pngis a URL of a single working tile. I believe thatslocounty-12in_EPSG3857
is the layer name in this situation.
Reply to this email directly or view it on GitHub:
#101 (comment)
Hmm, is EPSG3857 the same as EPSG900913?
i think this is a combination of coordinate origins and possibly a projection mismatch?
Also, consider that at zoom level 9, you can see buildings in your TMS, whereas a global TMS zoom level 9 shows some hundreds of miles... what is your datasource? Do you have a GeoTiff?
I think 3857 and 900913 are the same thing [1]http://docs.openlayers.org/library/spherical_mercator.html [2]http://jwalanta.blogspot.com/2011/09/reprojection-to-epsg900913-using.html @frewsxcv mentioned a possible origin/coord. mismatch - I think he'll be in the office in a couple days to research. But 3857 tested ok for me in QGIS with a layer in 3857 coordinates, that's what I don't understand. These are GeoTiff's that have been processed like so: http://docs.oam.osgeo.org/storage/creating.html ...eventually this dataset will be indexed in the OpenAerialMap process - perhaps another source to be used in MapKnitter...
Just following up with this issue, it looks like a zoom level issue. Investigating into how our MapProxy is set up
Since the extents of our aerials are different than the extents of the background layers, the TMS layers won't line up by design. As far as I can tell, there's no way in Leaflet to specify the extents of a sub-TMS layer (I think OpenLayers can though). Just for kicks, I forked @jywarren 's plots-leaflet-viewer repo and put it in our WMS instead and it works fine.
So i believe there should be a way to indicate extents in a TMS in OpenLayers... it's much more full-featured. What would such parameters look like in this case?
I hadn't tried the WMS display feature which used to be in MapKnitter but my experience was that it was very slow, so I removed it. I think we could resuscitate it given the current use case. Shall I?
The way Leaflet works is you just pass in a URL for a TileLayer and it substitutes in the {x} {y} and {z} fields and nothing more. For OpenLayers, you actually pass it the TMS resource URL (which is just the root of the TMS usually, example). As far as I know, OpenLayers actually calculates the offset and extents from this and correctly adjusts the layer (or so it looks here).
OK, well i put in the origin-corrected TMS into this test map: http://mapknitter.org/maps/tms-test
However, there is still a vertical ordering issue, perhaps related to an ambiguity in the TMS spec? We could create another feature in tmsfilter which allows for reversed vertical ordering... shall i?
Does tmsfilter assume the scheme to be x/y/z? Did you end up just caching our tiles and changing the extent to the entire world to make it work?
It makes the TMS use origin SW instead of origin NW (if I remember correctly). Code is here: https://github.com/jywarren/tms-filter
but if there are other common ways a TMS can vary, we could easily build them in too -- it's just a proxy.
I would like to close/merge/refresh this issue here: publiclab#45
I'm trying to recall if the main issue was resolved?