Allow base maps to be specified in init files

[JJediny]

Testing/Playing around with terriajs through a fork of the nationalmap. One observation is that in order to modify Basemaps

I'm pretty sure I'll have to use a modify this in TerriaJS -> and then manually compile TerriaJS instead of installing through npm as another stable dependency. Is there any reason why basemaps couldn't instead be handled as a json file in the map wrapper under datasources directory as datasources are currently from template/concatenating and load when the client is accessed from the "Map" wrapper? or Can they be currently overwritten if so where/how would this be done

[kring]

Hi @JJediny, thanks for checking out TerriaJS! To modify the list of default base maps, there's no need to actually modify TerriaJS itself. Instead, copy the entire source file from TerriaJS into your own project, modify it as appropriate, and use your function instead of the one in TerriaJS.

I do like your idea of specifying base maps using a JSON config file, though. We may do that at some point, and we'd certainly welcome a pull request for it if you're up for it.

[JJediny]

Without having dived in (yet) I guess the approach would be dependent on if Basemaps are currently handled any differently at run time. I saw three of the Basemap services used the ESRIgroup and WMS datasource object type - add X/Y/Z tile service (or lesser used TMS or ESRI's WMTS) and that's about all the services one could pick for available/external basemap services...

From past work in OL3 and Leaflet - I recall these libraries define whether a datasource is 'basemap' or 'layer' as a variable of the datasource object (ex. isBasemap: "True") with default set to False... ? Seems like that wouldn't disrupt the great work you all are putting into the datacatalog schema but get the same effect of managing basemaps as json datasource directory, thoughts?

[meh9]

@JJediny, controlling the basemaps from the config does indeed sound like a nice improvement. Another simple option in the meantime, if you just want to add a particular new basemap, is to use the existing Terria function and just add your own basemap to the list:

https://github.com/NICTA/aremi-natmap/blob/2015-08-26/index.js#L157

[JJediny]

@meh9 Thank you this is exactly what I was looking for - a place to hardcore new basemaps before load... If there's conscience on the best approach to move this into a json configuration let me know and I can try to pull together a PR?

[kring]

@JJediny I think it would make sense to read the list of base layers from another property in the JSON init files parallel to catalog called baseMaps or something like that. Each base map would be the combination of a catalog item, which can be deserialized from JSON using the existing function, CatalogMember.updateFromJson, and a URL for the image associated with the base map. Probably add the code to Terria.addInitSource. To completely replace the createAustraliaBaseMapOptions-type functions, we'll also need to extend CompositeCatalogItem a bit so it can be deserialized from JSON.

If you feel like tackling this, that'd be really great!

[JJediny]

@kring have some time and interest coming up to work on this... in taking another/fresher look at this I'm wondering if its easier to extend a new variable to a CatalogItem like thumbnailUrl that way when baseMap could be swapped with catalog in the json datasources still using the items collection extended from catalog but then on parsing/compile have baseMap load into the existing widget while catalog items stay as is? Might be too earlier in the morning to have thought this out well but let me know if I'm on the right track

[kring]

@JJediny great!

I like the idea of adding a thumbnailUrl to CatalogItem in order to eliminate the need for a special BaseMapViewModel and make basemap options just normal catalog items. Have I understood you correctly?

[JJediny]

Sounds about right ... I'll see if I can't get a PR vs another comment ;)

[nf-s]

Closed by #5140