What should we do with naming and awkward URLs #1898
-
Some of the documentation mentions naming things like your branch or your integration after the URL where you will be getting your schedule from. The issue I'm facing is that the host / url of the municipality is different than their trash schedule. They are using an arcgis map tool to show you collection information. I don't want to name it "arcgis.com" but I guess "planogis.maps.arcgis.com" would avoid ambiguity, but that's still not the host of the municipality itself. Which should I go with or something else? Is the most value placed on having the municipalities properly linked to, or the literal resource serving the data? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Does this source support multiple municipalities, or do you need to make changes for every municipality? If you can realize the source for multiple municipalities, I would name the source arcgis_com and add the supported municipalities with their URLs to the EXTRA_INFO section. (example). The update_docu_links.py will then add arcgis.com and the municipalities as extra elements in the README.md. If every there is no easy way to support multiple municipalities with one source, I would choose the municipalities' website for naming as it prevents naming conflicts, and it's more clear for the user. |
Beta Was this translation helpful? Give feedback.
Does this source support multiple municipalities, or do you need to make changes for every municipality?
If you can realize the source for multiple municipalities, I would name the source arcgis_com and add the supported municipalities with their URLs to the EXTRA_INFO section. (example). The update_docu_links.py will then add arcgis.com and the municipalities as extra elements in the README.md.
If every there is no easy way to support multiple municipalities with one source, I would choose the municipalities' website for naming as it prevents naming conflicts, and it's more clear for the user.