We want to start doing a lot more stuff with regard to locations in our stories. Specifically, we want to be able to geotag specific stories so we could theoretically do things like placing them on a map. We're doing a lot of exciting things with our local database of events, places, organizations and people, all of which would benefit from knowing the locations of many types of stories.
Right now, we don't see an effective way to do this with the tools in Arc.
In Composer settings, there is an optional field you can turn on for latitude & longitude. That's something, I guess, but the odds of reporters and editors looking up the latitude and longitude for stories they are writing is slim to none. (I also can't find anything about the field in Arc Answers, either from a backend development point of view or from a standard CMS one.)
What could be done to make actual geotagging of stories possible? Maybe at least adding an address search that would add lat/long data for a user without them needing to look it up?
Britton Peele
Hi Ruby! This additional context is very helpful. So it sounds like making this geo location data easier to add (and be accurate and scalable) is step one and then step 2, we need to ensure that stories with specific criteria (a neighborhood or city eg) can be easily aggregated so different teams serve up related content matching that criteria–either manually right now or through AI / more advanced audience targeting in the future– to your readers.
Hi Caytlyn. i want to share more context: Content Management involves labeling, categorizing and grouping content in a way that can be used for Audiences, Product, Engineering, Marketing, Analytics and others. I hope one day AI can help us to identify the geo-location interest of an article. but before that day of AI capability arrives, we still need human expertise- in this case the editors and reporters- to assign geo location address interest associated with a story.
Then, Marketing, Product, Engineering and other department can build features by querying, filtering and curating stories that are relevant to user interest personalization.
Hi Caytlyn. Internal searching would be helpful, but the primary need is for curation and personalization for users. For example, there are places we want to show stories that are relevant to users' interested counties and there are places we want to let people follow stories relevant to their neighborhood; there are places we may want to show stories near me. (we have ways to identify user geo interests, but we need Arc to associate articles with geo interests in a more scaleable way).
Yeah, that address field, longtitude/latitude fields are not realistic in a newsroom production flow. The user friction is too high and discrepancies for a high volume of editorial users on the ways of manually input data is troublesome.
No problem Ruby!
Thanks for the additional context here, so sounds like there's also a major need to be able to query stories based on this geolocation data too. This searching capability based of geolocation would be by authors searching for these stories, correct? Would they be searching just to see what stories have been written in regards to a specific neighborhood or city, or what else would be their end goal after they've searched?
This doesn't help with the current lack of search capabilities, but we do have a regular address field that is not currently enabled in your environment. It's still not ideal (you cannot search for an address and still have to manually input it), however would this help at least on starting to track this data on stories? Or is the real need both for the data and search capabilities.
Thanks for the update, Caytlyn.
Composer is really the key because that's the only place Content Management actually gets inputed. Once they are in Composer, I believe and hope we can query/filter them for wanted stories in other places, like PageBuilder.
One major wish is that if I search and input an address XXXX, Baltimore County, Maryland XXXX x for a story, I can find this story when I search this address neighborhood, city, county and state. It's like Yelp. Every restaurant has an address associated with it in Yelp. You can find a list of Italian restaurants in Fells Point neighborhood of Baltimore in Yelp. Think stories like restaurants in the Yelp context. We have an address associated with the story (and the address can be general like neighborhood itself or specific street or specific address), and then we can easily find a list of stories in Fells Point neighborhood.
Hi all, we still don't have immediate plans for this in the near future, but we'll continue to evaluate this as we make broader improvements to Composer. In addition to improving this in Composer, are there other needs with geo-tagging that need to be considered with how this may integrate PageBuilder, other arc apps, or other integrations to make sure we have a holistic approach and understanding?
I want to echo this ticket idea and SB-I-337.
Geotagging is so crucial and essential for local news publishers. The geotagging is the foundation for features like mapping, guide, customization and personalization. It's also the foundation for other geo-features for mobile app.
The existing lat/long fields are not enough because the chance for a reporter/editor to search for a location lat/long in the daily workflow to input that for a story is close to zero, considering that they dislike metadata in the first place.
We need to make geotagging experience more reasonable and realistic in daily workflow. Putting in an address search would be idea because that pretty much covers all the other options I was going to mention. If not, city, county and neighborhood would be minimal. But real ideal one would be an address search this ticket mentions.
Hi! I want to see if there are any updates about this idea!
Thank you for submitting this idea. I've merged it with a similar idea submission around geotagging to boost the votes, and we'll keep this on our radar for future consideration.