Now that more maps are being added and are being organized in multiple menus, it would be nice to have more control in the application for how URLs and routing occurs. For example, URLs for maps use the id property in the URL (e..g, #/maps/id). As more maps are added, it would be nice if the URL reflected the menu that initiated the map and file system folder used to organize maps, which tend to mimic the menus. For example, for Poudre Information Portal, maps on the file system are stored in assets/data-maps/BasinEntities/Physical-Counties/ and similar.
Is it possible and robust that a map identifier can include a slash? For example, change id=entities-counties to id=entities/counties? I'm not sure if I want to use the verbose names used for folders but using a slash would at least clearly show more of the hierarchy and could be consistent with the menus. The URL, when considered to be a resource identifier should not care what characters are used, especially when the actual location of files is handled in a different configuration property. Amazon and Google storage buckets take this approach.
I have similar thoughts about content pages but for now the high-level content pages are OK. Documentation for maps and layers is already being stored near maps and layers and may need to revisit what the URLs look like. Addressing this issue for maps
Maybe it makes sense to let the creator of the configuration file define the URL that will be used for a map or content page? For example, we could add an application configuration property like resourceUrl that could be set to, for example maps/entities/counties. If not specified, the default for maps could be maps/ + id. This would give full control of the URL routing to the person configuring the application. Need to discuss whether this has any real benefits (other than full flexibility) and whether it would cause problems.
Now that more maps are being added and are being organized in multiple menus, it would be nice to have more control in the application for how URLs and routing occurs. For example, URLs for maps use the
idproperty in the URL (e..g,#/maps/id). As more maps are added, it would be nice if the URL reflected the menu that initiated the map and file system folder used to organize maps, which tend to mimic the menus. For example, for Poudre Information Portal, maps on the file system are stored inassets/data-maps/BasinEntities/Physical-Counties/and similar.Is it possible and robust that a map identifier can include a slash? For example, change
id=entities-countiestoid=entities/counties? I'm not sure if I want to use the verbose names used for folders but using a slash would at least clearly show more of the hierarchy and could be consistent with the menus. The URL, when considered to be a resource identifier should not care what characters are used, especially when the actual location of files is handled in a different configuration property. Amazon and Google storage buckets take this approach.I have similar thoughts about content pages but for now the high-level content pages are OK. Documentation for maps and layers is already being stored near maps and layers and may need to revisit what the URLs look like. Addressing this issue for maps
Maybe it makes sense to let the creator of the configuration file define the URL that will be used for a map or content page? For example, we could add an application configuration property like
resourceUrlthat could be set to, for examplemaps/entities/counties. If not specified, the default for maps could bemaps/ + id. This would give full control of the URL routing to the person configuring the application. Need to discuss whether this has any real benefits (other than full flexibility) and whether it would cause problems.