TileDatabaseSettings layer url has no extension

[tmonk22]

In TileDatabaseSettings, I see three layers: imageLayer, detailLayer and elevationLayer. However, when reading, the reading function is called according to the extension of the url. If the url does not include the extension, for example, https://services.arcgisonline.com/ArcGIS/rest/services/World_Imagery/MapServer/tile/{z}/{y}/{x}, I can specify the extension through options->extensionHint = ".jpg";. However, if the urls of the three layers do not have extension names, for example, imageLayer is jpg and elevationLayer is png, what should I do?

[robertosfield]

vsg::TileDatabase was evolved to encompass a widere range of 3rd party data, so far it's always been for data that has a extension.

If a 3rd party service provider doesn't provide file extensions then a mechanism will need to be added to support this. vsg::Option's provides a mechanism for hinting what extension to assume fo istream/memory buffer data where no extension is provided, but as you point out this assumes a vsg::Option object for read.

To support the usage case of the of no file extension then the cleanest way would probably be to extend the variable subsitution syntax that vsg::TileDatabase/TileDatabaseSettings/vsg::tile presently uses to map the {x}{y} etc. to include a way of specifying the extension to assume. Or one could add a separate extension member variable for each layer to handle the usage case of data not having an extension. Or.. read the file and attempt to guess the type based on the header/syntax encountered.

While all these are possible I would flag up that vsg::TileDatabase is not meant to be a fully featured replacement for dedicated libraries like rocky/osgEarth. I have not intention for this class to keep chasing ever more sophsticated functionality that is beyond the scope of general purposed scene graph library.

So... if TileDatabase can be extended easily to handle other usage cases with minimal extra code and API complexiy then I'm open users add this functionality and generating a PR for it. Or if you want to comission me to add such features I'd be open to this as well.

[AnyOldName3]

If we're accessing URLs via HTTP/HTTPS, then they'll nearly always contain a Content-Type field in the response header with the MIME type, and clients are supposed to ignore the file extension (if present) and use this instead. E.g. the URL in the first post of this thread says it's Content-Type | image/jpeg. It would make sense to add the MIME type names to the lists of supported extensions for the VSG loaders, and have the CURL loader set the extension hint to the content type.

[robertosfield]

Interesting idea.