|
POST
|
That is correct. The Google Chrome browser (both desktop and Android) will not allow websites to request access to a users location unless the are not loaded over a secure (https) connection. This is a security restriction the browser puts in place to protect your privacy that a website cannot override. With an insecure connection, it is possible for anyone between you and the website's server to see your location (ISP, owner of a public wifi access point, or a hacker that has gained access to the network). Other browser like IE and iOS Safari do not have this same security restriction but they are left vulnerable to have your location accessible to others on the network. If you want to use this on your Android phone, you have three options: Contact the Franklin County GIS department and request they add a https certificate to their server so you can use the geolocate button (Best Options). The app does serve up an https version: https://gis.franklincountypa.gov/taxparcelviewer/, but because the server does not have a valid certificate, you will be prompted with a security warning. You can choose to proceed through this at your own risk by clicking the advanced options link then proceed link. If you do this, your location will be encrypted all the way to the app however, the browser just can't verify that you're sending it to Franklin County GIS department without that certificate. Look for another browser on the Google Play store that does not have this security restriction (Least secure option).
... View more
11-30-2016
04:56 AM
|
4
|
1
|
4428
|
|
POST
|
The "Tree Survey" app was a prototype that led to the current version of the Crowdsource Beta app. It uses a different code architecture and does not have a form editor or a multi select component built into the code yet. I just wrote a blog post about customizing the Crowdsource form but it will not be a simple addition, you'll need developer to go deeper in the code: https://developerscorner.storymaps.arcgis.com/custom-forms-in-the-story-map-crowdsource-beta-79af2014c8da#.a0gjvhboq. The crowdsource beta is built using a ReactJS architecture which does not alway play well with dojo dijits. I've already created a Select component and it should be pretty easy for a developer to modify that into a multiselect component. Once you have customized it, you will need a server to host the code.
... View more
11-29-2016
05:36 AM
|
0
|
0
|
903
|
|
POST
|
If you have created a new Story Map Crowdsource app through the online web builder, the only credit consumption should be the feature service storage. See this chart for specific pricing: ArcGIS Online | Service Credits. Each contribution is a new record in the feature service which is the first row in the table "Feature Services Storage." All photos are uploaded as attachments to the feature service storage and is calculated at the lower "Data Storage" rate. The photos are optimized in the builder before they are uploaded so each contribution should only be about 500kb of attachments per contribution. For a better estimate based on the number or records, data storage, additional map layers that may be added, you should contact your customer sales representative.
... View more
11-28-2016
04:37 AM
|
0
|
1
|
1532
|
|
POST
|
At this time, we can only support apps that have been fully created using the builder. There is a chance that modification made outside the builder will break with a future update. To be sure that updates do not break your published story, you can download the source code and host it on your own server. Then you can manually update the code when new version are released to see if they break your story before pushing the update to your server. The source code for the app is available here: https://github.com/Esri/storymap-crowdsource. Also, just adding new fields with the AGO assistant is probably not enough. In order to add additional fields, you’ll need to do the following: Add the additional fields to the feature service definition that the builder creates: https://github.com/Esri/storymap-crowdsource/blob/master/src/app/store/reducers/items/featureService/FeatureService.babel.js#L105 Then in the feature service application configuration, you’ll need to add a new settings object for each you field: https://github.com/Esri/storymap-crowdsource/blob/master/src/app/builderOptions.babel.js#L6. The key must be the field name from the feature service. These settings help determine how the form looks and how it should be displayed. Currently, the form understands text, textarea, location, and photo. If you need a different input type (such as a select input), you will need to add additional type checking and code to this file: https://github.com/Esri/storymap-crowdsource/blob/master/src/app/components/contribute/form/CrowdsourceForm.babel.js#L179 If you have a special way you need to save data back to the feature service, you can modify the save method here: https://github.com/Esri/storymap-crowdsource/blob/master/src/app/controllers/contribute/ContrbuteController.babel.js#L66. Finally, to customize the template used when displaying a selected point, you can modify this file: https://github.com/Esri/storymap-crowdsource/blob/master/src/app/components/selectedShares/SelectedDisplay.babel.js. At this time we do not have a release date planned for the final version of the Crowdsource App.
... View more
11-22-2016
06:03 AM
|
0
|
0
|
924
|
|
POST
|
At this time, the Beta version of the Story Map Crowdsource only supports a single photo. In future enhancements, we plan to allow you to customize the form as well as upload additional photos.
... View more
11-22-2016
05:45 AM
|
1
|
3
|
1835
|
|
POST
|
Hi Peter, Thanks for interest in story maps. As we continue to enhance our templates we are always looking for the best way to integrate multimedia within our apps, especially in ways that can be easily integrated with the GIS workflow. That being said, we pay special attention for how we integrate with every service we showcase in our builder, including our own services. First and foremost, Story Map apps are designed to be lightweight applications that allow you to tell your story to anyone you wish and should not be dependent on their browser connection or device speed. When we make decisions about integrating FS attachment support, we always want to provide the best user experience the end viewer. Feature services have powerful enterprise database capabilities but using them in certain ways can have detrimental effects on the end user performance. Both Map Tour and Crowdsource (and soon Shortlist) which are point based stories do allow you use FS attachments. When creating a new Map Tour, you will first encounter a screen that asks “Where are your image or videos?” If you choose the “ArcGIS” option, the app will create a FS in your account to store the point data. As you upload photos in the app, the app will automatically optimize the photos for the web and upload them as attachments to your feature service. It will then grab the URLs to these attachments and store them in field of the FS service so the app doesn’t need request each attachment URL every time the app loads. The map tour also allows you to use an existing FS with attachments if you create a new web map with that layer and share it into the Map Tour app. However, this is not recommended for the reason below. Crowdsource will always use a FS with attachments since that is layer type which allows other users to edit your data. The crowdsource app does not store URLs to the attachments in another field but works with the new query API call mentioned in reason 2 below. In our new Cascade app (and soon Map Journal and Series), we are also starting to use a new API call which will allow you to upload photos directly to the application item from within the app. These photos can be managed in the app builder or through the REST API and will keep the same sharing properties as the story you are creating. There are three main reasons that make it difficult for our apps to use FS attachments that have been added outside of a story map builder. Many times attachments that are added outside of our app builders will be the original quality photo that may be 4mb or larger. Even on a 3G connection, this may take 10+ seconds to load per image. All of our apps will optimize the photos for the web before uploading them as attachments. Our typical file size for large images are 2-400kb and for thumbnails is about 10kb. Typically, in most other apps (Collector, Survey123, etc.) or in a GIS workflow when you upload an attachment, the URL to that attachment is not saved into another field of the FS. In order to load an image attachment in a story, the app would have to make two requests per attachment. In many of our apps that use feature services, we have a thumbnail gallery to let the user explore all the points. In order to keep the thumbnail gallery, our apps would have to may have to make hundreds of additional requests as the app is first loading. This slows down the initial load time of the app (especially on slower connections) which is the most important period to keep a viewer’s attention. A new API has recently become available to ArcGIS Online hosted FS and may be rolled out to Portal and Server FS that allow us to query all the attachments with only a couple requests. As this become more widely available, we plan to integrate it into our app. Lastly, most of our apps require specific data structure such as 1 thumbnail and 1 photo per feature. When our apps upload attachments, we use a specific naming convention to determine which attachment corresponds with each part of the point display. Other apps (Collector, Survey123), maintain the original filename and we cannot reliably predict which attachment is which, especially if there are more than 2 attachments on a feature. We are in the planning stages to update our existing apps to make this more flexible in the future.
... View more
11-11-2016
07:25 AM
|
0
|
0
|
1358
|
|
POST
|
Yes, open the crowdsource in edit mode. Then open "Settings" and go to the "Social Settings." Then uncheck "Show social sharing buttons."
... View more
11-10-2016
11:32 AM
|
0
|
0
|
1991
|
|
POST
|
Unfortunately, the way social media sites get the title, description, and URL of a page is by reading meta tags that have to be hardcoded in the html of the page and cannot be dynamically inserted when the app loads like the rest of the content of your story (cover image, title text, etc.). Because of this, the only way to make these changes is to download the source code and change the content of these meta tags. We have a blog post about it here: https://developerscorner.storymaps.arcgis.com/grow-your-story-maps-audience-with-open-graph-tags-b7639cb65d5c#.235gf2s9s. Because you are embedding the story, you should actually place these open graph tags in your html of the parent page embedding your app. Then use the "og:url" open graph tag (The Open Graph protocol) with the content set to the URL of that parent webpage. The Facebook share is getting the "Error: Item does not exist or is inaccessible" because you tried sharing the link on Facebook before you made the story public. Facebook caches this result to make their service more efficient. You can tell Facebook to refresh their cache at any time by going to this page: https://developers.facebook.com/tools/debug/og/object/, enter the URL in the input, and click "Fetch new scrape information". The story map crowdsource app is a responsive app so when you embed it at a 640x480 px resolution, you are actually getting the same version a viewer would see on their smartphone. Because at this size, the title and subtitle usually fill most of the available cover screen, we have also extended the title background to fill the whole image. This helps keeps the text readably even to viewers with vision impairments. If you do need to change this, when you download the source code, you will find a place to enter custom CSS at the top of the body in the index.html.
... View more
11-10-2016
05:15 AM
|
0
|
1
|
1991
|
|
POST
|
Are you still having trouble? When I tried to share your link with the Facebook button in the app, everything worked as expected. Did you perhaps try sharing the link on Facebook before you make the story public? Facebook caches the meta data content it scrapes from a link to help make their service more efficient. If you shared the link before it became public, it might still show the "Content inaccessible" title and description for some time before it gets refreshed. If you ever change the title, subtitle, cover image, or sharing properties and want to make sure Facebook gets the changes immediately, you can use this tool: https://developers.facebook.com/tools/debug/og/object/. Just enter the URL to your story in the input and click "Fetch new scrape information."
... View more
11-08-2016
03:45 AM
|
1
|
1
|
927
|
|
POST
|
It looks like you have the additional fields added to the feature service and the data is being saved properly through the form in the crowdsource app. The one thing I would change, is the Link field type from "text" to "textarea." It will give you larger input in the form, but the app will give you a clickable link in the display. If this is the case, you should just have to list the additional fields you want to display in the app data. In the app data JSON, you should see: "shareDisplay": {
"media": {
"type": "photo",
"field": "PrimaryPhoto"
},
"displayOrder": [
"Description"
]
} You'll need to add the additional fields to the "displayOrder," in the order you want them to display: "shareDisplay": {
"media": {
"type": "photo",
"field": "PrimaryPhoto"
},
"displayOrder": [
"Designer",
"Description",
"Link"
]
} However, I'm not sure why description is not showing up since it should have been there by default. If items are not displaying correctly, or if you want to add labels above the text, you will need to modify this file: storymap-crowdsource/SelectedDisplay.babel.js at master · Esri/storymap-crowdsource · GitHub.
... View more
11-03-2016
06:59 AM
|
1
|
0
|
1263
|
|
POST
|
The Story Map Crowdsource app provides a very easy way to approve or reject submissions from the app so only appropriate content shows for your viewer. To start vetting points, open the app editor and click to "Explore the Map" on the cover page. At this point, a new dropdown should appear in the top right of the app that lets you filter which points are visible for review. By default, we only show new contributions on the map that are ready for review. When you click on a point in the map, the app will open the details panel for that point. This details panel is exactly the same content that will show in the public app with addition of buttons to Approve or Reject a post. Approving the post will make sure it's available in the public version as well as remove it from the "new contributions" filter so you don't have to review it every time you open the review mode of the app. Rejecting the point, will still keep the content available to you, but remove it from the public version of the app. To your additional questions, how did you add additional fields? At this time, we do not support additional fields that have been added in the hosted version of the app but we do plan to have a form editor in the future. However, it is possible to add new fields if you download the source code and modify it. You will need a developer to do the following: Update or Create a new feature services that contains the additional fields Define the field specification in the application data configuration If you are using to input type, you will need to add code the receive, validate and save the data correctly back to the feature service Update the details panel template to display the additional fields when it is selected.
... View more
11-03-2016
06:18 AM
|
0
|
2
|
1263
|
|
POST
|
Flickr splits photo sharing preferences and location sharing preferences into two different settings. Even if you have chosen to share your photos publicly, you also have to share the location of those photos as a separate setting in Flickr.
... View more
11-03-2016
04:14 AM
|
1
|
1
|
1468
|
|
POST
|
Yes, I believe most of the lag is due to processing power of the phone and your connection speed. Even if you are on wifi with both your phone and desktop, your devices may vary widely in speed. Desktop wifi radios tend to be much stronger, and may be able to work with more channels to get a stronger signal. If you haven't tested the speed from your iPhone specifically, it would be good to try that as well. fast.com, is a really easy site to do that. Also, the iPhone 5 is a couple years old and if you have continued updating the OS, you may notice that it is also running slower because the new OS requires more memory and CPU power. This will affect the browser speed as well. Also, check if your phone has less than 1/3 of the available storage left as this can start to significantly effect your performance as well. All that being said, I have noticed a few items that may improve the image load times if you are willing to spend a little time updating the app: All the thumbnails look like they are using the same full size photo as the main image which will increase your initial load time. It will also slow your performance on smartphones because it has to hold more data in memory. I recommend resizing to a width of 175px and compressing these to about 80% quality to reduce their size. Or store them on Flickr and import them in the app. (see below) It looks like your internal server hosting photos is a bit slow. This photo: http://anadisgoi.com/images/archive/1332/main.jpg, is about half the size as this photo on facebook: https://scontent.xx.fbcdn.net/t31.0-8/14242476_960994780678058_919529462775967431_o.jpg, however the first photo takes about twice as long to load as the Facebook one because the server it's coming from is slower. A photo hosting site is recommended in this case. When you copied photos from facebook, you may have copied various sizes without realizing it. Facebook will serve up different image sizes depending how big your browser window is. Before copying a photo from a photo hosting/social media site, resize your browser window to make the size of the photo is closer to the size you will use in your app. Also, we no longer recommend using photos stored on Facebook. Recently, they have changed their URL structure which makes them expire without notice and you may find photos disappearing from your app. My best recommendation, if you are able, would be to upload all the photos to Flickr and import them into the app using the Flickr importer built into the app. Flickr will automatically optimize your photos for the web and create different sizes. The Flickr importer will also grab the correct sizes it needs (one for the thumbnail and a larger one for the main image).
... View more
10-26-2016
05:12 AM
|
1
|
1
|
2196
|
|
POST
|
What sort lag are you experiencing? From looking at your app, the photos are loading in about 200 milliseconds on our ethernet and about 600ms - 1 second on a 3G connection. This is pretty typical for images. Are you're loading times much longer? Can you run an internet speed test on your phone? Also, we attempt to preload the previous photo and the next photo before you swipe. If a user stops to read the description and look at the photo, you should be able to swipe and have the next photo loaded already. The new issue you discovered should only happen if you are swiping through photos quickly. Because many smartphones do not have powerful processors and do not have access to the phone's full allotment of memory, we cannot render all the photos on the page at once without causing a slow or laggy experience. To solve this we only load three points into a swipable component at a time. The previous point off the screen to the left, the current point on screen, and the next point off the screen to the right. Every time you finish swiping, the app will update the previous point and next point and reposition the displays so you can continue swiping in the right direction. If you continue swiping before the update has finished, you may see an old point being replaced by the new point.
... View more
10-25-2016
11:46 AM
|
1
|
0
|
2196
|
|
POST
|
Hi Quanita, To clarify and correct Owen's response: All of our story map apps are "clientside" apps hosted on arcgis.com meaning all the source code and story configuration are hosted on arcgis.com. However, to render the page and and provide an interactive user experience, the code is download and run in a viewers browser. To correct Owen, the referrer domain used for the image request is the story url and not their computer's url. I believe the hostgator hotlinking protection should still work, however I have not used it before. You may need to be more specific in your list of whitelisted domains. Every story in arcgis.com has four main URL's to access the story. A generic arcgis.com url and an organization specific url, as well as an http and https version of both. For example this story: http://story.maps.arcgis.com/apps/Cascade/index.html?appid=46daf1304a0c4ad69a8935c7ed2ab692 Can also be access at: https://story.maps.arcgis.com/apps/Cascade/index.html?appid=46daf1304a0c4ad69a8935c7ed2ab692 https://www.arcgis.com/apps/Cascade/index.html?appid=46daf1304a0c4ad69a8935c7ed2ab692 http://www.arcgis.com/apps/Cascade/index.html?appid=46daf1304a0c4ad69a8935c7ed2ab692 Try adding all four urls to your whitelist. Alternatively, I recommend checking with hostgator support to see if you can use wildcard characters such as http://*.example.org/* to whitelist all combinations of a url for a specific host at once. If you still have trouble, you should contact hostgator support to verify you have entered the domains correctly.
... View more
10-25-2016
05:51 AM
|
0
|
0
|
1335
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 01-10-2018 05:56 AM | |
| 1 | 02-03-2016 11:13 AM | |
| 1 | 03-17-2017 07:22 AM | |
| 1 | 08-25-2017 06:35 AM | |
| 1 | 10-25-2016 05:09 AM |
| Online Status |
Offline
|
| Date Last Visited |
04-08-2026
08:01 AM
|