A guide to publishing content with confidence

GIS guru Simon Jackson joins Ta and Josh to explore the art of sharing intuitive, targeted mapping products with the web GIS world. Rather than hitting 'publish' and hoping for the best, follow Simon's three simple steps to improve data management, maintain security and accelerate delivery to end-users.


Apple podcast badgeSpotify podcast badgePodbean badgeGoogle podcast badge

Subscribe for more short, sharp and immediately usable insights. 

Join the conversation on Twitter @esriaustralia.

Stay in the know

Be notified when new episodes go live and submit your topic ideas below.

  • Click to view the episode transcript

    Sharing top-shelf maps and apps

    Ta: Now if you're adding data in shape file format to a map, then you get an option to generalise polygons as the data is added, that can be the difference between a snappy web map and a slug if your shape file is laden with vertices.

    Disclaimer: This podcast is brought to you by the team at Esri Australia. To get your hands on more short, sharp, and immediately usable resources, head to the Esri Australia website, and search for goldmine.

    Ta: Welcome to GIS Directions. I'm Ta Taneka

    Josh: I'm Josh Venman.

    Ta: Now this week, we're joined by guest host, GIS guru, amazing colleague and friend Simon Jackson, as Wayne is off working on an exciting project, which I'm sure we'll all hear about in due course. So welcome to the madhouse Simon.

    Simon: Thank you Ta, it's an honour to be here.

    Ta: Now today's topic is one we're all familiar with professionally.

    And as a new mum, I'm getting more acquainted with this personally and that's sharing. Yay. Now we're all taught to play nice and share our toys in Kindy. But do these early skills really translate to web GIS? Now, what are the secrets to creating, publishing and sharing great content in a web GIS world?

    Josh: Good question. ArcGIS whether, it's ArcGIS Enterprise or Online makes it really simple to do those things. But, it's not just pressing buttons, there's an art to this process.

    Simon: True. And that art element is what we're going to explore in this episode. how to level up your web GIS publishing skills, and really make a difference with your web GIS content.

    And I'll kick things off with an overarching design principle that's so vitally important and that's considering your target audience. Now this has been true since the earliest days of cartographic map design. And it's no different today. Who is your information for, what is their level of understanding of the subject, and what's the actual message that you're trying to convey to them?

    Ta: And actually, if you follow that one principle, then good things tend to follow because if you do understand your audience well, you're much more likely to create a well-targeted, effective, easy to use information product.

    And the trick is to take the time to do that rather than just hit the publish button and hope for the best.

    Josh: Totally agree with that. And there's a whole accessibility angle on that too, which we've talked about in previous episodes. I know Wayne's really keen on that. But let's dig a bit deeper and talk about the three steps in going from raw geospatial data to a published web map or, even a web app, creating, publishing and sharing.

    Ta: I'll kick things off with step one and that's to create. Now, this is where you're assembling the layers that make up your map and deciding on how you're going to present them to deliver the intended message. Now, an area where people often go wrong here is overloading the map. And we've seen this time and time again.

    Now that could mean several things. It could be too many layers which really spells confusion for the intended user, or layers that are too complex or busy and they obscure the message. Or layers that are just too slow for the intended use. And that's one of the biggest things that we've come across is performance.

    Simon: Yeah, Ta this first step is critical. authoring decisions made at this point can really have a major impact downstream, taking a layer where the data does not change much, but the user needs to see a large number of features.

    Adding this as a feature layer to a web map, that's going to be used by many users will likely lead to performance problems. Now, a good tip here would be to consider publishing a hosted map image layer off the back of that hosted feature layer, or even using vector tiles as an alternative. Now that first tip might seem a little strange, but it is a really good one to know, publish your map as a hosted feature layer.

    Then add that feature layer back into Pro, maybe apply some fancy symbology if that's what you need, then publish it again, as a map image layer. You then have the benefits of using that feature layer if you need it. But also, the map image layer to accelerate the delivery of that map to those end users.

    Josh: That really is good tip. I've used that myself and you definitely wouldn't stumble on it by accident. Would you? We'll, we'll make sure we include the link to the documentation on how to do that, cause that's absolutely gold. I'm going to throw in another one on creation that's to consider the simplest most efficient way of storing the data that actually sits behind your map.

    So you might think of an enterprise geodatabase or data in the Portal's Relational Data Store as part of a hosted feature layer. But if you had a really small amount of data, just say a handful of points or even a couple of a hundred points, you could think about doing it in a slightly different way. And that's using a feature collection and you can really turbo boost the performance of your map that way. In that scenario, the data gets stored in the web map itself rather than outside in some kind of data store.

    And the best example I can kind of relate to on this one is, you know, when you drag and drop a CSV file or a GPX file, it's the kind of classic web GIS demo and magically the points appear on the map, that's what's happening there. By default, that data gets jammed into a feature collection of a web map and get stored with a web map and a little work really fast. Now, of course, if you want to edit the data and you want to do fancy things with it, then it's not going to be the solution to the problem, but it sure is fast.

    Ta: Now, one final thing from me on step one in creating and building on what Josh just described. Now if you're adding data in shape file format to a map, again, for smaller amounts of data, then you get an option to generalise polygons as the data is added. Now, this is really a game changer because that can be the difference between a snappy web map and a slug if your shape file is laden with vertices.

    Simon: Yeah, that's a great one. I've seen so many times when you take a boundary, like a coastline or a statistical area boundary, that's really complex, and a lot of the time when you zoom in, you're never going to need that level of detail.

    Ta: Mmm, absolutely.

    Josh: Yeah. And it kind of often is driven by what the authoritative data set defines. So like if you download ABS data, it has all the detail because that's the data they have but do you need it is the question?

    Simon: All right. So step one. You've got a map that's a thing of beauty and we've optimised it as best as we can for performance. What do we now need to consider for step two? And that's the publishing process?

    Josh: Yeah. Look, first up, I'd say, take a breath, pause and consider where your data's gonna end up. I've come across quite a few scenarios in my time where a web map that's been out there for a long-time using services from the organisation's ArcGIS Enterprise comes up on the radar, not in a good way because the data appears to be stale.

    And when folks go and try and explore how to refresh that data, they actually don't know where it's coming from. It just kind of came from ArcGIS. And a common scenario that leads to that is when someone said yes to the simple question, "copy data to server?" When they go through the publishing process. And if you do that what can often happen is it will get shunted into a file geodatabase on the ArcGIS server, in a specific folder, and it'll work, but it'll kind of be lost forever. So that's a really important one is to think about exactly where the data is going to end up when you hit that publish button.

    Ta: Absolutely the old, "where is my data stored?" Mystery. Now it can get pretty complex, but if we focus on the features side of this, so your points, your lines and polygons, then the question to ask is, is the data in this map from a source that's only on my machine or one that's in a shared location, like Josh said, in an enterprise geodatabase.

    Now, if it's only on your machine, then if you're going to make your map available to the masses, you're going to have to put it somewhere that's shared. The typical target in this case would have to be your data pushed to the portal as a hosted feature layer, where it ends up in the relational data store.

    And on the other hand, if the data you're using is say from an enterprise geodatabase then you definitely don't want to create another copy of it. In that case, you want to use a registered data store, a bookmark, if you like to the shared data location. And it tells Pro to just use the data where it already resides.

    Simon: Yeah. And a good tip for GIS admins, you can actually make your experience for the ArcGIS Pro publishers a lot easier by preregistering your enterprise geodatabase in your portal as a data store item. By doing this, it'll actually show up automatically at the publication time. There's a great white paper that we'll include a link on the website that explains the differences between these user managed data stores with enterprise geodatabases. And these ArcGIS managed data sources such as the ArcGIS relational data store.

    Josh: That really is a good document., I've referred people to that many times cause it's, a, a source of great confusion. All right. So, steps one and two complete, we've got a web map and it ticks all the boxes, it's getting data from the right location. But at this point it's likely only visible to you, the person who published it. And that's by design. it's your decision as to who you share it to. Default sees you as the only person who can access it until you choose to share it more broadly.

    So, what wisdom can we collectively offer at this point? How can we share with confidence?

    Ta: Well I'll jump in here, first word of caution on how caring and sharing you are. Now, depending on the way your Enterprise or ArcGIS Online organisation is set up, as well as your user privileges, you may have the power to share to everyone.

    Now, if that's the case, then probably you're trusted to wield that power responsibly. But always stop and think before you do that, since ‘’everyone’ means your entire organisation in the case of Enterprise and literally the whole internet, in the case of ArcGIS Online. You don't want to go viral in a bad way.

    Now call me cautious if you like, but my tip is, make sure that capability isn't enabled by default for all users. Now you can make sure the right people have the right privileges using custom roles. And groups here are your best friend in making sure the right people see the right content when it's time to share.

    Josh: Hey Si, I'm going to jump in here, mate, because I think you've got a hot tip off the back of that, what's that tool that people can use to analyse their ArcGIS Online organisation that picks up that setting and, and a whole bunch of other useful stuff?

    Simon: There's a partner tool from GEO Jobe that allows you to sort of see all of the dependencies on items, sort of work out, when you share this, uh, who's it going to be shared with? Is that the one you're talking about?

    Josh: That's a great one, but there's also like a security scan tool isn't there? 

    Simon: That's a brilliant one. Yeah. The security advisor tool under trusted ArcGIS, yeah. I highly recommend running that one.

    Josh: Yeah, that’s it.

    Simon: I've definitely learned the hard way of accidentally sharing content to everyone and, sometimes the wrong types of data getting out. It's one of those things you should apply at the role level. Another one that catches people out, including myself quite frequently is just understanding that items depend on other items.

    So you can have a web map and you've added some layers to it and you share the map, but you might not have shared the layers and this isn't gonna work, a user when they hit that map, they're going to be challenged to login because one of the corresponding layers hasn't been given access to them. look, ArcGIS is pretty good at telling you when this is the case and saying, well, look, if you're trying to share this map, do you also want to share the layers in the same way, but this is also a good moment just to take a breath and sort of work out well, do you want to share those layers in the same way?

    Maybe they've got editor writes on them. A nice way of getting around this is actually instead of sharing the hosted feature data, creating what we call hosted feature layer views. Now these allow you to have different views of that underlying hosted feature data, but maybe with, without those editor permissions or filtered down to particular areas or filtering out some of the fields that might be confidential. And then you can share the map and these views with relevant audience without having to worry.

    Ta: Very nice.

    Josh: That is a good one. And am I right in saying you can have multiple views on the same data, if you want to have different spins on it?

    Simon: That's right? Yeah. So, you can have different views with different audiences in mind.

    Josh: A final one for me and don't yawn, but it's around metadata. Don't tune out! I know, it's not the most exciting thing to talk about, but what's the point in going through all this kind of due diligence, all these best practice steps we talked about to get your web map or app just right. And then nobody can find it. So, discovery is important.

    If you wanted to, if your organisation goes down this path, you can actually implement kind of full traditional metadata, ISO ANZLIC-like metadata in your web GIS if you want, but I'd say if you just follow the basic minimum of giving your item a good title, consistent tags and a meaningful summary, then your work of art is going to be easily discoverable and we could do a whole episode on this, but maybe another time!

    Simon: A whole episode. I mean, Meta data is such an important topic, but, uh, it's also quite a boring topic!

    Ta: I would leave this at the good old TOSLA so title, orientation, scale, legend, blah, blah, blah. That's where I'd leave it.

    Josh: All right, on that note, let's wrap it up for today. As always, we'll make sure we include links to everything we've discussed today on the website so you can dig deeper and that's gisdirectionspodcast.com.au.

    Ta: And we'd love to hear anything publishing and all publishing tips from you guys. So jump onto the website to send them through, or connect with us on LinkedIn or Twitter.

    Josh: Thanks for joining, us until next time.

    Simon: And as Wayne would say, stay spatial!

    Ta: Happy mapping (and publishing).

    Disclaimer: The views and opinions expressed in this podcast are solely those of the hosts, and do not necessarily represent the views or opinions of Esri Australia.



Subscribe to
Esri Australia news