|
POST
|
Yes, see: https://community.esri.com/community/gis/web-gis/storymaps/blog/2017/03/19/arcgis-blog-how-to-launch-a-story-map-series-at-a-specific-entry And here's a blog post that reviews all the supported URL parameters: https://community.esri.com/community/gis/web-gis/storymaps/blog/2017/07/27/story-maps-developers-corner-using-story-map-url-parameters Rupert
... View more
11-20-2018
09:21 AM
|
1
|
0
|
967
|
|
POST
|
For issues related to accounts and subscriptions, especially if they are preventing work going ahead, we'd also recommend contacting Esri Technical Support directly so they could walk through your situation.. Rupert
... View more
11-20-2018
08:47 AM
|
0
|
0
|
483
|
|
POST
|
I get the same error. A good way to investigate is to try and access the entry for that Story Map in ArcGIS Online. If I copy the appID of that story out of my browser's address bar and then search ArcGIS Online to find the entry for that story (by pasting that appID into the search box and preceding it by "id:" https://www.arcgis.com/home/search.html?q=id%3A6b2c1091521e45e2aa3e633d4634f783&t=content&start=1&sortOrder=desc&sortFie… I can find that item's entry. Then if I open the item: https://www.arcgis.com/home/item.html?id=6b2c1091521e45e2aa3e633d4634f783 I get the message that the ArcGIS Online subscription associated with this item has been suspended. Perhaps first double-check that account. For example, can the user sign in to ArcGIS Online and create a new map, or new Story Map? Rupert
... View more
11-20-2018
08:36 AM
|
0
|
1
|
483
|
|
POST
|
Hi The embed bar is something we added to Story Maps this year. There were many cases where authors were embedding story maps in web pages in fairly small frames without providing a way to maximize that story for better/easier viewing, especially on mobile devices. So the embed bar provides that capability automatically. It can also appear when you embed Story Maps in other Story Maps, as you point out. When you embed a story inside another story , the embed bar get automatically suppressed if the ArcGIS domain (i.e. myorg.maps.arcgis.com) of the story you are embedding is the same as the ArcGIS domain of the story you are embedding it into. To see whether the embed bar will appear for stories embedded in your story map, be sure to preview your story, because that rule doesn't kick-in inside the builder. So for example if you embed a story map that is on www.arcgis.com into a story map that is on a different domain, like myorg.maps.arcgis.com, it will have that embed bar. To suppress the embed bar when you embed stories created by other authors in your story map, access those stories using the same domain as your story map. So if your story is on myorg.maps.arcgis.com you can access any publicly shared story via that URL, and the embed bar won't appear. Alternatively, you can add the &classicEmbedMode parameter to the end of the URLs of the stories you embed, i.e. https://cityofcambridge.maps.arcgis.com/apps/Cascade/index.html?appid=dc50eccdc77d4ec7ab2e9de89630e5c0&classicEmbedMode To suppress the embed bar when you embed stories in web pages, you can add the &classicEmbedMode parameter to the end of the URLs of the stories you embed. Hope that helps Rupert
... View more
11-16-2018
04:15 PM
|
3
|
1
|
3096
|
|
POST
|
Hi Lytton Sorry about the issues you've add because your project sounds fun. However Story Map Tour isn't designed for this sort of collaboration. With the exception of our older Story Map Crowdsource app, the Story Map apps are basically single-author/single-owner but with some ability for editing or management by several authors, or a single overall editor/administrator as described in the doc you referenced. It's not designed to be as collaborative as crowdsourcing. One of the caveats is that our place-based app templates, Story Map Tour and Story Map Shortlist, (which are the ones that people are often keenest to collaborate on because they assemble large sets of places), store the places that are authored in an associated web map that is managed automatically by the builder, and in the case of a Map Tour built by uploading images, an associated feature service too. So for the place-based apps especially, there are a lot of moving parts that make collaboration hard and not easy to set up. At least, I don't know if anyone has been able to set up what you are describing. One more collaboration possibility that we should also mention is setting up a Google Sheet that you add into a web map as referenced data. If that Google Sheet uses the data schema that the Map Tour expects (see the sample CSV file you can download from the Story Map Tour builder's Advanced options in its Welcome dialog), you can publish the web map as a Map Tour and then multiple editors can edit that Google Sheet and those edits can get reflected automatically in your Map Tour. Shortlist supports the same workflow. The big drawback with this workflow is that it requires that your pictures are referenced via URLs as attributes in that table, and putting images onto the web so they can be referenced that way is not easy and only really aimed at people with access to web servers for hosting, so unless that's the environment you are working in, it's a lot of work. So I think in general the best way for a class to collaborate on a Story Map is to do the collaboration on the editorial/content assembly part of storytelling, rather than the technical part. Even without the difficulties mentioned above, I think this can be a good approach. So a class could be divided up and responsibilities assigned for assembling the content for a Tour (concept, overall story, title/subtitle, choosing maps and what layers they will show, pictures and their captions, story color and layout, story social media appearance, proof-reading, etc) and then have one person actually build it. You could even have multiple people building the tour, but simply working in shifts with the same account. We do that quite a lot! People responsible for pictures and captions could email that content to the person building the story. I know it doesn't sound super high-tech but might be good approach, especially as it matches pretty closely how a lot of Esri customers are creating story maps in their organizations, and how we create stories in our team here. The technical part of actually building a Story Map from the editorial content is pretty straightforward, it tends to be researching and assembling that content that is the harder but more fun part. Or perhaps other with experience of this would like to weigh in? Rupert
... View more
11-16-2018
02:00 PM
|
0
|
0
|
574
|
|
POST
|
See also this corresponding blog post about Story Map parameters. It doesn't address this particular question, but I thought it would be good to mention: https://community.esri.com/community/gis/web-gis/storymaps/blog/2017/07/27/story-maps-developers-corner-using-story-map-url-parameters Rupert
... View more
11-16-2018
09:59 AM
|
0
|
0
|
605
|
|
POST
|
Hi Adrian Good points you raise. Uploading images into Story Maps doesn't consume a lot of credits. I don't know the figures but it is much less than, for example, publishing GIS datasets as services. I don't think it should be a concern for most users. Story Map Tour (our oldest Story Map app) and Story Map Crowdsource (now in Mature Support) are the only Story Map apps that require an ArcGIS subscription to upload images, because they use a feature service to store the images. The other apps don't require a subscription to upload images. Going forward with future Story Map app development we most likely won't be using the pattern of storing uploaded images in feature services. This is for several reasons, but especially because it makes stories harder to manage because the images aren't stored directly with the story. I think going forward with our future development you'll start seeing less support for using images stored in photo hosting.sharing system, like Flickr, in the storytelling tools, rather than more support or support for new systems. As you alluded in your intro post, gateways to those systems tend to be hard to maintain as the APIs, business models, and terms of service of those systems change. Authors may also not realize that when they use Flickr/Google+ images in Story Maps that those images are referenced in those systems from the story, not loaded into the story, so if the owner the picture deletes or unshares it, it won't appear in the story. But the biggest issue is that the terms and conditions of those systems generally frown on them being used as silos for images just as a way of getting those images online for use in other systems. This is why we are careful not to describe or recommend a system like Flickr as a way to get images into Story Maps, and instead say that if you or an organization is already using that system to share images, being able to add them into Story Maps is a convenient added bonus of that using system. The exception to this are curated photo sharing systems like Unsplash that can be used as a source of rights-free, high quality images to make your work look great. Story Map Cascade lets you find and add Unsplash images directly in the builder. These aren't ways to host your own pics, but they let you find pics that photographers want to share to the community. I think in general you may start to see less support for referencing images directly via URLs. I mentioned that in my last comment as one way to handle large sets of images for place-based stories. On average though this capability tends to be misused in stories rather more than well used, because authors often link to huge files that slow down their stories, but they don't realize this is the case because that image gets cached in their browser the first time they view it, and after that seems to load quickly. It is hard for us to check for overly large images in our builder user interfaces and My Stories, and some authors assume incorrectly that we optimize images referenced via links. Plus images authors find on the web on random websites and link to via URLs always seem to break just before they present their story to a large room of people! So image upload is still the best way to go so we can optimize your pics and store them conveniently. Sorry for overly long posts! Rupert
... View more
11-15-2018
04:14 PM
|
1
|
4
|
4958
|
|
POST
|
Hi Chris I've tried this and like you I couldn't get this to work: if I configure a story action that turns on a layer in the it seems to apply an extent as part of that action, so if a reader manually zooms in and then clicks the action, the extent of the map changes back to what it was before. I'll check into this and see if it is a known issue in Story Map Series. Rupert
... View more
11-14-2018
05:04 PM
|
1
|
2
|
1010
|
|
POST
|
Hi Adrian Officially, our support for photos in Flickr and Google+/Picasa has always been intended as a way for people and organizations who are already using those photo sharing systems to easily integrate them into Story Maps, and also provide a way for Story Map authors to access photos that other folks are already sharing publicly using those systems. For example when you access Flickr images from the Story Map builders you can enter the name of any author in order to find albums they are sharing publicly (so if you enter 'Rupert Essinger' you can access my public albums). In addition, in Story Map Cascade you can search Flickr publicly shared photos by keyword to add into your story, the same way you can search and access Unsplash images. We've never intended Story Map authors to use Flickr or Google+ solely as a way to get photos into Story Maps, Flickr is a really nice place to host and share your photos, and being able to add public photos from Flickr into Story Maps easily is an added benefit of doing that. For example if you add Flickr images into Story Map Tour or Story Map Shortlist we pick up the geolocation, name and caption that is stored in Flicker for each pic. So if you work for , say, a non-profit that maintains a public Flickr album of pics, you can use them directly in your stories, or if you use Flickr already for sharing your own pics it is great. But we don't recommend getting a Flickr account solely as a way to get your pictures into Story Maps. To add images into a Story Map our recommendation is always to upload your images directly into the Story Map builder. That's the easiest and most secure way to add images into Story Maps: your photos are stored in the story (or, in the case of Story Map Tour, as a layer in an associated web map) and are given the same sharing status as your story (so if your photos are confidential to your organization no one outside your organization will be able to access them if you only share your story within your Org, which is obviously not the case with Flickr/Google+), You also don't have to worry about photos being deleted or unshared in Flickr or Google+, especially if you are not the author, or worry about someone else on the web using one of your publicly shared pics in a way you might not expect or intend. (For example I mark my Flickr pics as public domain which is the most liberal sharing status, but it still felt a bit weird when one of my Hiking Trip to Mammoth Mountain pics was used in an online feature in Elle Decor magazine: they did credit me as the photographer but for public domain pics they don't need to notify you). If you have a large number of images you'd like to use, such as 50+ pics for the places in a Story Map Tour or Shortlist, I'd recommend putting those on your own web server, such as your agency or business's own web server or website, and simply referencing them via URLs. In this way you can manage your pics as a set of files and do things like include their URLs as attributes in map layers or spreadsheets and build your Tour or Shortlist in batch from those instead of one-by-one. That workflow isn't possible with image uploads or Flickr/Google+ images. You could reference images that are already on the web using URLs but the big issues with doing that are that their file size is often way too large for good draw performance, and images that you don't manage yourself have a tendency to be deleted or renamed without you knowing about it. Referencing images via URLs in Story Maps does not optimize the images automatically, like uploading them or pointing at them in a system like Flickr does, so you will want to be able to manage their file size yourself if you have a big database of images. For example for my Tours and Shortlists about San Diego I pick from a set of 200+ of image files I have put onto an Esri web server and that I have resized for good draw performance. So if you go this route you should definitely check the Story Map FAQs to find out the recommended image size for the Story Map app template(s) you want to use. Rupert
... View more
11-14-2018
04:02 PM
|
1
|
6
|
4958
|
|
POST
|
Here's the Story Maps FAQ about duplicating a Story Map: https://storymaps.arcgis.com/en/faq/#question17
... View more
11-09-2018
12:51 PM
|
1
|
0
|
5379
|
|
POST
|
Hi Tony I'm not sure what would cause this. If you still see the issue and it is stopping you from working, I'd recommend contacting Esri Tech Support so they can walk through your scenario with you. Rupert
... View more
11-09-2018
10:49 AM
|
0
|
0
|
516
|
|
POST
|
Hi Melanie Sorry about the delayed reply. I can reproduce this issue and we are looking into this for our December update. Rupert
... View more
11-09-2018
10:47 AM
|
1
|
1
|
1256
|
|
POST
|
There's no longer a limit in Shortlist. Our original, download only version had a limit of 99 per tab because at that point we ran out of numbered marker icons . In the current version of Shortlist we generate the markers on the fly, so there's no limit. However for best performance and the comfort of your readers, we'd still recommend not exceeding 100 or so places per tab in a Shortlist. For really huge numbers of places (i.e. thousands), a web map containing clickable points, perhaps with photos in their popups, will be faster and easier to author with your GIS than a Shortlist. Rupert
... View more
11-08-2018
02:29 PM
|
2
|
1
|
750
|
|
POST
|
You could still use an app like Survey 123 to gather info from them and add it to a map. It is only the automatic transfer of collected pics to Story Map Shortlist that doesn't work well. There's not a direct equivalent of Story Map Crowdsource. That app is still supported and can be used still. It is just in mature support. We do hear you about wanting something like that though. Please see this FAQ about it too: https://storymaps.arcgis.com/en/faq/#question25c Rupert
... View more
11-08-2018
02:24 PM
|
0
|
0
|
674
|
|
POST
|
Thanks for the note. I'll review that in Firefox and see if I can reproduce it. Can I check if you are using Firefox on a PC or Mac? Rupert
... View more
11-08-2018
09:50 AM
|
0
|
2
|
1050
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 09-06-2018 11:42 AM | |
| 2 | 05-16-2016 08:08 AM | |
| 1 | 08-06-2018 05:11 PM | |
| 1 | 09-29-2017 05:38 PM | |
| 1 | 09-05-2018 03:14 PM |
| Online Status |
Offline
|
| Date Last Visited |
11-11-2020
02:22 AM
|