Hi Tom,
My question wasn't clear, or you did not answer my question ;-)
I was looking for a compelling *use-case* where the solution requires a
tile server to support both jpeg and png for a given tileset. My stance for
mapcache is that the data producer (i.e. you as the mapcache administrator)
knows his data and therefore which format (*singular*) is best suited for a
given tileset. I'd be happy to revisit my judgment if presented with a
scenario where more than one format per tileset is actually needed.

Cheers,
Thomas

On Tue, Nov 22, 2016 at 12:19 PM tellett <[email protected]> wrote:

Hi Thomas,

Really, its just so that we don't need to have 2 separate layers in the
service for each format type. The norwegian mapping authority has about 25
cache 'services' and so its a bit messy in the config and WMTS capabilities
file if we have to have 50 tilesets instead of 25.

Its no problem technically having 2 tilesets called 'topo2_png' and
'topo2_jpeg' for example (they would have the same title and abstract), it
just would have been preferable for us to have 1 layer support multiple
formats so that the client could call the same service/layer/tileset and
choose the format type through the kvp parameter. Not a show-stopper for us,
we just have to change our way of thinking :)

Tom



--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Mapcache-support-for-multiple-format-types-tp5296486p5296917.html
Sent from the Mapserver - User mailing list archive at Nabble.com.
_______________________________________________
mapserver-users mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapserver-users
_______________________________________________
mapserver-users mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapserver-users
  • ... tellett
    • ... thomas bonfort
      • ... tellett
        • ... thomas bonfort
          • ... Cechini, Matthew F. (GSFC-423.0)[Science Systems & Applications, Inc.]
            • ... thomas bonfort
              • ... tellett
                • ... thomas bonfort

Reply via email to