State of Colorado GIS Portal Launch
Great news yesterday out of the GIS in the Rockies Conference. I was planning on going to the conference this year, but just got so busy I could tear myself away from work. Remember what Jack says about being successful at GIS:
“Now is the time to be the last one out of the parking lot”
The Colorado Geographic Information Portal is now available for users to get access to publicly available GIS data. My company does quite a bit of work in Colorado these days and getting data was always a PITA as many different organizations had to be contacted to get datasets. So I was very excited to see what Colorado put up for their portal, especially since it launches after big changes in the Geospatial world. Alas, I was very disappointed in what I saw as it is just another GIS portal powered ESRI’s GIS Portal Toolkit. The biggest problem is that the ArcIMS front end is so dated and slow. If this was built on the WebADF or even better ArcGIS Server, there would be so much more functionality. In the end this is the same, cluncky interface that we’ve been used to for years on the Geospatial On Stop.
Vladimir Lenin rails against holding geographic data hostage to proprietary formats
The second disappointment is that the data is still really only available as standard shapefiles and saved jpg format. There is no real OGC support let along KML/KMZ support that would enable more users access to this data. I’m fine with no WMS/WFS services as that is an strain on resources for most public entities, but all this data should be available in shp, gml, kml/kmz, tiff, jpg, pdf, and ecw. I’d take shapefiles over anything, believe me, but the lack of KML support is very surprising.
OK, lets not get too negative here. Metadata is great for finding datasets and the Colorado Geographic Information Portal is loaded up with great metadata. If you are looking for data from Colorado, you’ll be able to find it easily with the search. Actually this is the one area the ESRI GIS Portal Toolkit gets right. It took me no time to track down data that I will be needing for a project near Colorado Springs using the metadata search.
So what do we have here? A great new resource for folks looking for data from the “Centennial State”. It is as clunky as any GIS portal out there so I guess this is expected, but there needs to be more focus on data formats beyond shapefiles and an improved mapping front end that should be viable inside Google Earth (and probably powered by ESRI’s WebADF). It is a good start, but most of these GIS portals start well and end up getting stagnant over the months/years. Maybe Jon Gottsegen’s new powers as GIO will enable him to be more nimble and able to make improvements to the portal to make it the first “Where 2.0″ data portal out there.
Recommend any stellar portal sites?
What-chu-talkin-bout slow?
Any search I did came back in less than a second, every page I hit came back fast…well thats the web server and not ArcIMS. I agree it does have the look and feel of an out of the box portal, but I can’t gripe about performance.
the images returned aren’t slow but the old fashioned GUI is.
I am not a big fan of these “portal” sites especially Geo-one stop. I prefer “gimme all you got” bundles like what Mississippi (MARIS) offers or a clear directory of data such as Kansas (DASC) or Missouri (MSDIS) offers. That being said, i’ve always been able to find most of this data for Colorado through Google or agency sites with little hassle…
Yes, all of us ESRI users are “the last ones out of the parking lot” because the ESRI software is so damn slow!!
Jack, ESRI GIS users are always the “last ones out of the parking lot” because your software can be so slow!
The Colorado portal is not responding at all now, but it’s good to see some efforts being made in CO. That state has been off the map too long.
“Stellar portal” is an oxymoron. What is it with GIS and portals? I’ve got two words for you: Web API.
Suggish as hell…
What’s the point in wasting all those big bucks on an implementation like that when you could spend a few hundred dollars on an implementation like this http://map.niagarafalls.ca/ ……includes AJAX calls, HTTP compression, dynamic legends etc etc and on top of that it’s lightening quick.
for me colorado is a bit chunky niagarafalls is a bit bumpy.
Sean…..
I’m curious and I am not questioning your opinion. Why WebAPI?
KoS
I’m the GIS database coordinator for the state of Minnesota Dept. of Nat. Resources - we have a portal, the “DNR Data Deli” (http://deli.dnr.state.mn.us) that is built around MapServer, but is showing its age. We are beginning to brainstorm about what our next generation GIS data portal will look like and how it should function.
I’d be very interested to hear some more from you all what your ideal portal would encompass. What are the must-have features, what would be icing on the cake, what technologies would you expect a top-notch portal to take advantage of?
So far I see:
1) Solid metadata with quick searching and results that are easy to sift through.
2) Dynamic interface (AJAX, etc)
3) Data delivery in multipile formats (KML/KMZ support, ECW, Shapefile, others.)
4) A web mapping front end that is viable inside Google earth… (I’m not sure exactly what you are visualizing here).
5) More … ?
The state of Israel lunched its GIS portal at http://www.govmap.gov.il.
It does not support English yet (soon) but still it can give you an idea how you can squeeze the max out of ARC IMS
you know what IMS the niagra falls app uses I assume…
hal
how about simple ftp access.
KJ, the Niagara site uses Manifold IMS…like I said, a few hundred dollars. There’s a few nice things from Telerik to do with .NET but the GIS engine behind the app is Manifold.
brian - when you’re offering 200+ layers, vector,raster, image in a variety of formats, tiling schemes, etc… ftp just doesn’t cut it.
I’ll throw a few things out:
- Clip requested data sets to a boundary that you can upload (or trace onscreen, snapping to features you see onscreen)
- Ability to preview data layers (with annotation) prior to download.
- Ability to have data delivered in any coordinate system/projection.
- Google Earth/Virtual Earth / ArcExplorere style interface (globe with interactive panning, raster backdrops)
- Export selected layers with annotation to GeoPDF at a variety of scales.
- Export to GPS compatible formats, along with the standard GIS formats.
Hal, works for California and their portal.
ftp://casil.ucdavis.edu
I am trying to determine whether ArcGIS server Enterprise or ArcGIS Workgroup is what I need. I can’t seem to get any straight answers from anyone. We want to take state and local GIS data (i.e. crime, property, highways,developments and etc) and present the maps and the data online. I’m concerned that I cannot get adequate configuration info out of ESRI. I want to make sure our sites visitors have a good experience. Speed is the issue. Any help would be appreciated. Thanks
“I am trying to determine whether ArcGIS server Enterprise or ArcGIS Workgroup is what I need. I can’t seem to get any straight answers from anyone. “
For size and capacity planning you may want to email sihelp@esri.com. They can be very helpful. But you will need to provide a lot more details than you listed.
Workstation apps are easier to spec - one installation per one user. A web app is different completley - multi-tennant means one app can house many users. So to figure your “configuration” you really need to factor in a myriad of things like the number of users, peak load you want to design for, size and location of your data, online to the public to online to your intranet, the web server hardware you have available, just to name a very few. There is no easy config for this. These questions will be the same for any GIS server, Arc…, Manifold IMS, mapserver, mapguide, etc. - no getting around that.
So far, ESRI is the only vendor I can find that has performance and capacity planning models for GIS server and web app serving.
But you can get pretty good idea of the difference between Workgroup and enterprise just by reading the web site, or calling them on the phone.
For capacity and config planning the definitive guide is the ESRI system desigh guide:
http://www.esri.com/library/whitepapers/pdfs/sysdesig.pdf
… and sihelp@esri.com can help with running the models for your scenario.
Thanks. The problems is when we put up new databases we will get 50-100,000 hits a day. ESRI configuration data really doesn’t help. They just tell me that Workgroup will work. Of course, that doesn’t tell me much. The server and software I pick out must provide a reasonable response over the web. Many of the government sites I’ve been to run 5-15 seconds a layer. I’m sure they aren’t getting 50-100,000 page hits in a day and who knows how many DB access.
I thought maybe someone out there has gone through this.
Thanks
ok - I would still contact sihelp unless you already have - it is possible to actually compute repsonse time given your spec - number of processors, type and speed of processor, ESRI server software, bandwidth you have to the Internet, number of concurrent hits you want to design for, etc. - its not magic, its just not easy. None of the other GIS server vendors can provide that information, that I personally have seen. I would not base any decisions for an important system on annecdotal blog responses or emails w/o doing a real technical analysis (there are just too many variables) - but I admit I too am interested in hearing what people have to say on the topic.
It’s a joke, regardless of whose engine they use. No real data there. I’m wondering if the Colorado Geological Survey does anything except write tourist brochures.
I have to agree with Hal. I much perfer a good ole ftp download vs. a nice fancy interface.
That’s why I was curious as to why a webADF or any other “fancy” interface.
I’m at the point were plain and simple is good. Fancy and complicated is bad.
KoS
State of Colorado is and will always be an ESRI shop, so trying to get anything out of them besides same old technology is not going to happen. No KML; no Manifold; nothing. Most likely it is written in ArcIMS because of the time it take them to do anything; technology change quickly government works slowly.
just to to be fair the niagra falls manifold site does nothing special that you can’t do with ArcIMS - its not as if Manifold IMS has a customizable AJAX viewer using some slick telerik controls on it, you have to program that all from scratch yourself and purchase the telerik controls from telerik - you could do the exact same thing with ArcIMS. I am not ripping on manifold or anything, just that’s not one of the benifits.
I totally agree, but you missed the point. ArcIMS costs thousands (and you’ve still got plenty of coding work to do if you want a decent site) whilst Manifold costs hundreds (so you’ve got plenty of cash left over for a bit of programming). In terms of cost the two solutions are worlds apart. Also, to the best of my knowledge, none of the ESRI kit runs on 64 bit operating systems, whereas Manifold does.
I didn’t miss the point , but maybe you did. I was simply pointing out that there are benifits and costs for both. So in the discussion above some people looked at that niagara / manifold site and implied that crummy old ArcIMS could not do that cool UI stuff. In fact it can - in the same way that Manifold does not provide you with AJAX viewers to modify, or telerik AJAX controls that you have to buy separatley - you have to program from scratch in Manifold.
But to answer your “roll your own code with all your saved money” argument - Manifold IMS may be better in some cases, but not better in others. It just depends on what you want to do. For example, its great about the 64 bit stuff, but if you have a really big site where you need multiple GIS servers sharing and balancing load, and you need to separate the GIS server tier from the web application tier, - Manifold IMS has nothing built in to do that. What if your web GIS app needs more capacity than a single 64 bit quad core server can give you? Then you have to roll your own unlike in ArcIMS. Programming on your own will cost you really a lot of money - its no joke, and and is that really what you want to spend your money programming, or do you want to spend money programming your own unnique features. Similarly, read the object model for ArcIMS (many hundreds of pages), and compare to Manifold IMS (couple of pages). If you can do what you want in the more limited Manifold IMS API, or roll your own custom code in a cost effective manner, then great - but if not you will be spending a lot of money programming broad horizontal stuff that ArcIMS already has. So you can stand up a web GIS app for less money with Manifold, and more money with ArcIMS, but you can also spend more money in the end getting the Manifold web app complete, depending on the features you need to put in. Another example, the topic of this thread - ArcIMS with the GIS Portal Toolkit - Manifold IMS has no GIS portal capabilities, so you have to roll your own. Custom programming, even for just 4 weeks, can cost you many thousands of dollars, including requirements, design, programming, unit test, integration test, feature testing, negative testing, rework, documentation, not to mention maintenance and updates and fixes - and then what if KJ the programmer gets a offered a new job with stock options and a beemer - then maintaining all that broad horizontal stuff costs you even more to maintain, and you might wish you had only your vertical custom code to worry about. Its actually not all that easy to find really really good Manifold IMS web developers - there are a few out there, but not thousands.
So for me its just not clear cut which is better. Sometimes one is, sometimes the other is - it just depends on what you want to do. Yes, cost is a benifit of Manifold IMS . No, out of the box RIA AJAX UI experiences, GIS Portals, and server load balancing are not a benifit of Manifold IMS.
I personally know the developers behind the CO portal site and can attest to the drunken binge parties in Boulder the night before this portal went live …. wait, there was no mention of the parties was there. Crap.