How to configure TMS endpoint: boundingbox, origin, and units-per-pixel?

Mar 3, 2016 at 4:12 PM
Edited Mar 3, 2016 at 4:23 PM
I have a TMS endpoint that works fine in Leaflet, but I'm having trouble configuring it to work in ArcBruTile.

In my TileMapService xml, the TileMap entry looks like this:
<TileMap title="NIR 2013" srs="EPSG:3857" type="TMS" profile="local" href="http://www.richlandmaps.com/ftpwww/nir2013.xml"/>
Then, in my TileMap xml, I have the following..
<SRS>EPSG:3857</SRS>
<BoundingBox minx="-22041259.1770679" miny="-28118208.4285695" maxx="21975562.428403" maxy="28183905.1772344" />
<Origin x="-20037508.340000000000000" y="20037508.340000000000000" />  
Along with several TileSet entries that look basically like this one:
<TileSet href="http://f.richlandmaps.com/tilestache/tiles.py/s3-nir2013/10"
                          units-per-pixel="0.00068664550781250000" order="10" />
With this configuration, ArcMap just seems to hang like it's stuck in an infinite loop. Definitely not working in that configuration.

HOWEVER.. if I flip the type value in TileMapService xml, so that it's type="InvertedTMS", the layer will render, but it renders in the wrong hemisphere. Basically I expect that, because I provided the wrong type/orientation value. But I don't understand is why it doesn't work with the correct orientation value??

Again, I know the layer works, because it works in Leaflet, and it even "works" in ArcBruTile with the wrong type value.

Because I have a different layer that IS InvertedTMS, and it works correctly in ArcBruTile, my suspicion is that it must be the values I'm using for boundingbox, origin, and/or units-per-pixel in this broken layer that I've described.

So what am I doing wrong that it breaks when I provide the correct type value? Any ideas?
Mar 3, 2016 at 4:19 PM
Edited Mar 3, 2016 at 4:21 PM
If it's helpful, here is an example of a couple working URLs from the TMS endpoint:

http://e.richlandmaps.com/tilestache/tiles.py/s3-nir2013/9/140/307.png
http://f.richlandmaps.com/tilestache/tiles.py/s3-nir2013/9/141/307.png

And this is the leaflet configuration that calls it. Actually this is from our config file, but these are exactly the values we pass into Leaflet:
{
    "name": "2013 NIR",
    "label": "2013 NIR",
    "enabled": false,
    "layertype": "L.tileLayer",
    "endpoint": "http://{s}.richlandmaps.com/tilestache/tiles.py/s3-nir2013/{z}/{x}/{y}.png",
    "options": {
        "tms": true,
        "subdomains": "efg",
        "maxNativeZoom": 20,
        "maxZoom": 21,
        "opacity": 1,
        "attribution": "2013 imagery &copy; Richland County"
    }
}
Coordinator
Apr 5, 2016 at 7:02 PM
I can reproduce this in ArcMap, tiles are rendered in the wrong hemisphere with type = "InvertedTMS".
I tried some options in the xml files without luck. I think this needs custom code to render correctly.

Maybe you can change the configuration in TileStache so that y-axis is changed?
In the Leaflet config the "tms": true option needs to be removed after that.
Coordinator
Apr 11, 2016 at 9:03 AM
actually I got it working, you need to add overwriteurls="false" to your TileMapService xml
You can test it 'Add TMS Service -> Richland -> Richland NIR 2013.
Config files:
https://dl.dropboxusercontent.com/u/9984329/ArcBruTile/Services/Richland/richland.xml
https://dl.dropboxusercontent.com/u/9984329/ArcBruTile/Services/Richland/nir_2013.xml
Marked as answer by elrobis on 4/11/2016 at 12:22 PM
Apr 11, 2016 at 7:21 PM
@bertt thanks for looking into this! I was able to modify both XML files as you suggested and it works. One more question, our original raster pyramid for this dataset (NIR 2013) is saved and stored in Amazon S3, and the S3 endpoint uses .png files along the exterior, where there is transparency, and .jpg files within the interior, where there is no transparency. I didn't want to fight with two possible problems while getting this working, so I used TileStache as a proxy, which results in all tiles being forced into the .png format. However, if I were to remove TileStache, would ArcBruTile be able to read the S3 tile endpoint if the tiled images were a mix of .png and .jpg formats? If so, what value (or not) would I use in the TileFormat node of the TileMap .XML fle?

What we have now is..

<TileFormat width="256" height="256" mime-type="image/png" extension="png"/>

Soo.. can we possibly just omit the mime-type and extension attributes? i.e.

<TileFormat width="256" height="256"/>

Thanks again for your help!
Apr 11, 2016 at 7:36 PM
Edited Apr 11, 2016 at 7:37 PM
PS. I just tried this, without either the mime-type or extension attributes, and ArcBruTile threw the generic error:

Object reference not set to an instance of an object. (ArcBruTile)

Program Location:
at BrutileArcGIS.lib.CacheDirectory.GetFileCache(String baseCacheDir, IConfig config, EnumBruTileLayer enumBruTileLayer)
at BrutileArcGIS.Lib.BruTileLayer.Draw(esriDrawPhase drawPhase, IDisplay display, ITrackCancel trackCancel)

Is it possible to pass in a wildcard value for either mime-type or extension?
Coordinator
Apr 11, 2016 at 7:45 PM
no, that scenario with mixed image types is not supported. Whats the url for the original S3 tile endpoint? Maybe I can
add it in next release if not too complicated.
Apr 11, 2016 at 7:59 PM
@bertt, thanks for the quick response :)

Contents of the TileMap xml file I created to test, including the original S3 endpoint, appears below. Thanks again for looking into this!

Best Regards,
Elijah
<TileMap version="1.0.0" tilemapservice="http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013">
          <Title>S3 NIR 2013</Title>
          <Abstract></Abstract>
          <SRS>EPSG:3857</SRS>
          <BoundingBox minx="-20037508.342789" miny="-20037508.342789" maxx="20037508.342789" maxy="20037508.342789"/>
          <Origin x="-20037508.342789" y="-20037508.342789"/>
          <TileFormat width="256" height="256"/>
          <TileSets>
             <TileSet href="http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/0" units-per-pixel="156543.033900000" order="0"/>
             <TileSet href="http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/1" units-per-pixel="78271.516950000" order="1"/>
             <TileSet href="http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/2" units-per-pixel="39135.758475000" order="2"/>
             <TileSet href="http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/3" units-per-pixel="19567.879237500" order="3"/>
             <TileSet href="http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/4" units-per-pixel="9783.939618750" order="4"/>
             <TileSet href="http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/5" units-per-pixel="4891.969809375" order="5"/>
             <TileSet href="http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/6" units-per-pixel="2445.984904688" order="6"/>
             <TileSet href="http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/7" units-per-pixel="1222.992452344" order="7"/>
             <TileSet href="http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/8" units-per-pixel="611.496226172" order="8"/>
             <TileSet href="http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/9" units-per-pixel="305.748113086" order="9"/>
             <TileSet href="http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/10" units-per-pixel="152.874056543" order="10"/>
             <TileSet href="http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/11" units-per-pixel="76.437028271" order="11"/>
             <TileSet href="http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/12" units-per-pixel="38.218514136" order="12"/>
             <TileSet href="http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/13" units-per-pixel="19.109257068" order="13"/>
             <TileSet href="http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/14" units-per-pixel="9.554628534" order="14"/>
             <TileSet href="http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/15" units-per-pixel="4.777314267" order="15"/>
             <TileSet href="http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/16" units-per-pixel="2.388657133" order="16"/>
             <TileSet href="http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/17" units-per-pixel="1.194328567" order="17"/>
             <TileSet href="http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/18" units-per-pixel="0.597164283" order="18"/>
          </TileSets>
</TileMap>
Coordinator
Apr 17, 2016 at 8:10 AM
can you give a working sample url?
something like http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/4/4/10
Apr 19, 2016 at 3:34 PM
Yes sir, sorry for the slow response! Here's two example urls:

This one is a JPEG..
http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/16/18014/39353

This one is a PNG..
http://rcgeos3.s3-website-us-east-1.amazonaws.com/imagery/nrg2013/16/18013/39353

These are neighboring tiles. The vendor used PNGs along the original image boundary to use the alpha band for transparency, and JPEGs through the image interior, which of course are 3 band. I suppose they did this to reduce the size on disk (and also streamline network throughput) for the tile set. Not sure.

Thanks for continuing with this!

Best, Elijah
Apr 19, 2016 at 3:38 PM
Just for my own reference, this is the location in our web mapping application where I used Fiddler to track those tile paths:

http://www.richlandmaps.com/apps/dataviewer/?lat=33.98361&lon=-81.04804&zoom=16&base=aerial&expanded=53759|52088|18518|38669|39665&layers=33844|24029

You'll have to select either the Imagery or Hybrid basemap type, then select "2013 NIR" as the imagery option.

/E
Coordinator
Apr 19, 2016 at 8:21 PM
ok thanks, I'll look at this after the upcoming 0.7 release, cannot do a quick fix now