We are looking at making some maps available on our website, which are hosted on a server in our building, and I was wondering what internet speeds would be acceptable for this, as well as how many users (very roughly) we could expect to use our maps. This map would be for a rural municipality in Canada, with a population of about 8,500.
That's a pretty wide open question and will depend a lot on a range of factors.
For example, are you pushing Imagery through the pipe? That will eat up bandwidth.
How's the connection from the hosting server to the internet?
What's the ISP in use, how are you connected, how's the bandwidth allocated, etc...
How about the download/upload speed from the server to the ISP?
The GIS Wiki might have some info or tools that could help you out: http://wiki.gis.com/wiki/index.php/Main_Page
Most ISPs have much slower upload speeds than download. At least for the common consumer's link.
Business are usually different. But if you're a smaller muni using a standard ISP in the area, it could be that all your map service requests to your server could look like an upload to the internet and be throttled back.
Does that make sense?
I actually think you are a perfect candidate to utilize ArcGIS online.
Put your data and map out on AGOL and then it will scale as needed depending on the number of hits the website is taking.
If you're sensitive to credits, you could always host your data on an internal server, make the data available to AGOL but then put your map out there. If the map were public to everyone, that scenario would consume no credits (I think...)
If you have AGOL host your data, you'll have some credit consumption but credits really are pretty cheap.
As an example, I put a 200 MB data file up on AGOL and it runs about 50 credits a month for AGOL's credit cost for Storage. Credits cost 10 per $1 in blocks of 1000. So that's $5 a month and Esri deals with the server, scaling, etc...
That's the way I'd go, given the info so far.
Thanks so much for your response!
We have some cached imagery that we would be serving out, as well as multiple maps that we would like to make available to the public.
Our internet connection right now is a wireless connection, with 5Mbps up and down, but we were looking into upgrading to a 50mbps up/down fibre line.
We already had the ArcGIS Server infrastructure installed before I came on board, so I'm not sure if we would want to move to AGOL.
My gut tells me the 5mbs would be too slow for imagery but you could always try it and then upgrade the pipe if needed.
I'm sure you know that AGS and AGOL aren't mutually exclusive. You can continue to use AGS internally and AGOL for the public facing side and/or a combo of them. Since you have AGS, it means you also have a certain number of named users for AGOL based on your AGS license (unless you have an ELA, then Named users are negotiated differently.) You could serve up your data from AGS, make it available on AGOL and publish a web app there that consumes the data from AGS. You'd use no credits in that case but you would be pushing your data through your ISP pipe. If your AGS is behind firewalls and if you're using SSL, it gets trickier. The easiest way to avoid those problems it is to publish the data up on AGOL.
I think these days most organizations that are using AGOL or Portal are doing a hybrid of AGS, AGOL/Portal. Obviously if using Portal, you have AGS in the mix. And even groups with Portal often use a combo of Portal and AGOL.
To be honest, AGOL makes it so easy to publish data for public consumption and there is a slew of data out there already from the OpenData project.
In our case, as a water utility, we use Portal and AGS (with a Silverlight Mapzilla) internally. We're slowly getting Portal off the ground. We will use AGOL for a few public facing things that some groups are interested in publishing.
The point I'm trying to make is that you can make this stuff all work together and with AGOL, you have a huge breadth of tools at your disposal, a Portal that is administered by others, scales as needed, etc... I imagine you know that there is already imagery as a basemap available in AGOL. If you're like us, we fly our own Ortho-Imagery, in conjunction with other local gov entities. We do this to get a higher resolution than the standard available imagery. But to be honest, if I think about what our folks use imagery for, I imagine the Google resolution is perfectly adequate. Our 3X better resolution is useful for some entities, like Assessors, but I suspect our field guys mostly use it for reference and orientation.
You can always give AGOL a try. Publishing your own imagery to it is not something I've tried because we're talking a lot of data. But you could serve it up from your own server and then publish other layers to AGOL to create the public maps you want. I'd recommend just playing with it to see what it can give you. Use the free imagery basemaps initially and if it looks like something worth pursuing, then dig into it using your own.
Of course, you've already got your maps published and running so why invent the wheel. But you can also use AGOL as the Portal into your maps. You register your maps with Portal as an existing app and they show up in the Gallery. Lots of options. Where I've seen AGOL really successful is with the smaller entities that don't have much of an IT staff. With AGOL, you've got Esri basically being your IT staff for internet apps with the benefit of all the apps they make available to us now. I imagine you know about the Local Government Solutions.
Best of luck!
You also may be interested in what I can offer. I provide GIS Server Services for a post secondary institution in Western Canada along the same lines what you are describing here, not AGOL tied. The machines are dedicated servers on 1Gb/s connections. You RDP in, you control, publish, do what you want, your ArcGIS Server / Portal sit there. I can probably do it all, including the machine for less than your 50up/down Telus connection costs alone.
What Paul is missing is that Imagery from AGOL for Canada is atrocious. some areas being 7+ years old and/or awful resolution.