What are your biggest challenges when developing GIS software?

Is it coding? Is it understanding cartography/geography/etc concepts (like projections)? Or other difficulties?

  • 1
    I LOVE this discussion. I know its an old thread, but the information is GOLD. I work for Esri as a Product Manager of developer products. I look after ArcGIS Runtime SDKs (Java, Android, Qt) and ArcObjects SDK for Java. First of all, I can empathize with the pain. Second of all, I'd like to hear if the Web APIs and the ArcGIS Runtime APIs have helped mitigate the pain points in using the Platform, or just in general. Handling lots and lots of data is still a challenge i suppose, bit is it getting better...now 5 years later? Services, both from Online and Portal, are getting more robust. Are t
    – user52397
    Commented May 20, 2015 at 1:53
  • Hi Eric, welcome to GIS.SE. Always good to see software company employees participating in the community. We're a little less discussion forum here and more specific Q&A. You might want to check out the tour. We do have a chat for conversations, though it isn't heavily used. You might also take a look at our tagging system. Using that you can hone in on recent question activity on a particular subject, like the APIs and SDKs you mention.
    – Chris W
    Commented May 20, 2015 at 2:36
  • Likewise welcome to GIS SE Eric! As you look around the site some more, I hope you will quickly get what Stack Exchange is all about, and how different its focussed Q&A format is from a discussion forum. It's precisely what I had hoped the ArcGIS Discussion Forums would become in their most recent overhaul. However, please don't judge its value on this early Q&A which, despite its popularity, is not a great example of how users can come here looking for an answer, and within a few minutes identify the same question and read its answer without having to digest a back and forth discussion.
    – PolyGeo
    Commented May 20, 2015 at 3:01

15 Answers 15


Speaking from my experience as a developer who fell into the ESRI/GIS development scene nearly 5 years ago:

  1. There is no single API to do what you want to do. Only a muddled mess of APIs that may or may not work for your purposes: ArcObjects, Python, REST, SOAP, ADF, ST_Geometry operators?
  2. All of the APIs are tied to some clunky, expensive piece of software that you would rather not place at the core of your application.
  3. Little opportunity for truly creative design. Object-oriented geospatial data structures? Forget it. Despite all the talk about "objects" and "feature classes" you're still working with dumb tables mediated by capricious middleware.
  4. The software is buggy, error messages misleading, and documentation incomplete. Troubleshooting is almost always trial and error. Get used to it.
  5. Managing geospatial data using relational database methods is nearly impossible. I have pretty much had to abandon any SQL/DDL because they just get me in trouble with the middleware (yes, I'm talking about ArcSDE). It's a shame to throw away an entire skillset. Just open ArcCatalog, point, click.

As you can tell I have a pretty negative outlook on the ESRI development scene. For those who come from a geography background, I'm sure the possibilities are pretty exciting. But for someone like me who loves relational databases, object-oriented programming, and wide open opportunity for creative solutions, GIS development with ESRI is very constraining and unfulfilling. This is a shame because the old school crowd tells me that it used to be a superior environment, before the alignment with Microsoft. I sincerely hope the open source community continues to innovate.

  • 4
    I'm a statistician, and I have very similar complaints about ESRI products. My overly-optimistic theory is that, because computers were probably applied to stats before GIS, GIS software is about ten years behind statistical software (in its SAS/SPSS phase) and that a truly outstanding open-source program or stack is on the verge of breaking out. Maybe it already has - it's been years since I've had the chance to play with non-ESRI programs. Commented Aug 13, 2010 at 15:40
  • 2
    I'll just chime in to virtually shake my fist at Redlands with the rest of you, and pass along an illustrative anecdote: Pretty much any API call into Spatial Analyst's raster APIs (at the time) would fail with a generic COM "Unspecified Error" if anything went wrong. Desperate to troubleshoot, I ended up connecting strace to ArcGIS.exe and, buried in system calls, found (drumroll) that helpful and detailed 1980s-era error messages were being written to the windows equivalent of /dev/null.
    – Dan S.
    Commented Mar 27, 2011 at 17:16

Large amounts of data. Being able to figure out the right way to extract large amounts of data using web technology has been a challenge. We can either have a lot of data, and poor performance, or have a lot less data being displayed, but potentially conveying the wrong information.


I'm not a GIS developer; however, I'm a GIS modeller:


  • Data gathering, aggregation, disaggregation, merging, and splitting: I get data from various sources for different projects; the biggest problem is usually getting all the data for the same geographic parcel/area. I usually have to use a few of the above mentioned techniques on every data set, to have a coherent sample for the project. This increases error likelyhoods and dilutes our precision.

  • I'm not a developer; I repeat I'm not a developer: When you lovely people talk about SOAP, SHAMPOO, REST, GIS-T Indexes, etc.. this means a lot to you. To me mostly it's jargon. I usually have a large learning curve or a steep climb to get some of the simple things done.

  • The gap between FOSS and Proprietary Software: I love QGIS and postgis to death; literally i have them installed on every machine; however, when I want to do a transportation based analysis, I have to resort to TransCAD or EMME2/3. Each costs about $15,000 with all the bells and whistles. In all fairness, all these problems could be solved if there was a networkx package for shp files.

  • Multiple disciplines issue: I'm well versed in transportation modeling techniques; however suck at demographic modelling, and as far as I can tell, I have to use sophisticated R tools to get my data done. So the GIS Problem is that GIS is a multidisciplinary field that is hard to survive on your own.

  • Lack of well established tools and software to go from imagery land use to vector land use: I foresee a future where a tool will analyze GEOEYE satellite image and compare the land uses in it to a vector (as built) database

  • Sometimes it is faster to do things in Excel/"your fav spread sheet program goes here: Sometimes I want to do transit analysis, it's a lot faster to grab the data put it in excel, do the formulae work, then dump the data back into postgis as a csv file and regenerate the map. Such a divide especially in the OpenSource world should be better handled.

Anyways I may not have answered you correctly; I just wish I was well versed when it comes to GIS programming so i can excel in GIS modeling

  • Networkx for shp already exist FYI e.g.networkx.github.io/documentation/latest/reference/… For vector + raster, see PostGIS raster extension trac.osgeo.org/postgis/wiki/WKTRaster
    – ThomasG77
    Commented Jun 9, 2013 at 19:12
  • +1 biggest problem is reliable data sources. A lot of states will hire college interns for summer jobs to go around collecting coordinates for roads and stuff, and usually not error checked or audited at all (not even samples of it), and result is now you have New Jersey DOT saying that a road is 500 feet shorter than Google and OSM says it is. Goddamit. Commented Jan 6, 2017 at 21:44

The most important things, and usually the hardest in my experience, are:

  1. get the right data for the job
  2. get it to show in the proper projection (and having all the layers agree.) Especially when they come from different sources
  3. design a usable application. It's easy and tempting to put a lot of bells and whistles that will only confuse the users

I think that point 1 will be easier in developed countries, but that's not my experience.


To me, the biggest challenge is deciding which tools to use for a given project. Open source or proprietary? Python or .NET? Web-based or desktop? I answer these questions differently for different projects, and I'm sure people will ask all of them on this site. A lot of it comes down to personal preference and trying to divine what ESRI and Microsoft will support in the future.

  • This would have to be the biggest thing for me.
    – Nathan W
    Commented Jul 22, 2010 at 22:05
  • 2
    This is less important for me. While it is in the best interests of the developer to invest in their own future, and to avoid "wasted work", I feel that the ends justify the means, and whatever technology does the job is the best choice. Having a clear idea on what you need to deliver is more important than how you get there.
    – mwalker
    Commented Aug 13, 2010 at 17:39

My issue is all about the horse and the water. In a lot of cases we develop and or present really good solutions for our clients, but no matter how elegant the solution, it is absolutely useless if no one will take the time to use. In some cases, we have been able to alleviate this by making our work user based (survey for issues, talk about solutions prior to development) but it some cases this is still not enough.


I think the hardest challenge is to get management to understand GIS and some users just don't get it either. The perception is that GIS is about making a map; that a map is the sole outcome of any GIS endevour. I can't tell you how frustrating I find this - the level of ignorance out there is huge, and it's held by the key decision makers.

Eventually though - we being some of the pioneering GIS experts and programmers - will eventually become management and then we can finally get some decent GIS projects done!

The other hard thing as a GIS programmer - you have to understand so many different technologies, Java, .Net, databases, ESRI software or other vendors i.e. MapInfo, networks, security, web tech, etc etc. It's an almost impossible job sometimes!


Dealing with people from a surveying background who don't understand professional software development techniques and methodologies, but because they taught themselves how to code avenue/VB, think that's all there is to it.


#3 from Vinko's answer:

design a usable application. It's easy and tempting to put a lot of bells and whistles that will only confuse the users.

I'd vote for the whole answer but for the fact that usability is only the third item in his list and i don't think the first two are that challenging.

Usability is where most of my issues are and where i spend most of the design/development time, figuring out how to design an intelligent and effective user-interface, but keep it intuitive so that users aren't confused by it, for example:

  • How to tune the styling (and choose the layers) of an interactive map to show the relevant information and avoid the clutter that often comes with displaying too much data (e.g. by using automatic aggregation of point features); i know this is what cartography has been trying to solve for ages, but the problem only gets worse with digital/interactive maps

  • How to do automatic positioning of the map view based on the user's query/feature selection

  • Highlighting the 'selected' features - do you show the highlight just briefly, have it highlighted the whole time a feature is selected, do you un-highlight when the selection table (or list) loses focus... How to highlight both all query results from a table and the selected row within that table (without having too many toggle buttons)

  • Showing additional information in lists of layers or features, e.g. a layer's visibility/applied style/geometry type, feature's status/class... This gets even more complicated in case one has different feature types displayed in the same list (i guess that's why Google and Bing Maps use quite heavy filtering of the search results)

  • Efficient editing: snapping, closing of polygons, adding/moving/deleting points, without having lots of toolbar buttons.

  • How to do design (and implement) a user-frendly query interface for geometry queries, and even more challenging, an interface for queries including both attributes and geometry; without making the user type in something resembling SQL.

  • How to design something like a clipboard for features/geometries to avoid having to continuously 'pick' a feature off the map for use in queries, edits...

My feeling is that GIS is an especially challenging field in the usability aspect, because:

  • Location is the universal and usually the most natural context for any information, so there's always too much information available for display

  • Having information displayed on a map, one is easily tempted to underestimate the importance of the non-GIS parts of the user interface

  • The industry has traditionally neglected the usability aspect of GIS software, and they got away with it because digital mapping was seen as a technical trade with a slow learning curve and there were far more difficult concepts to learn than how to use the interface. This means that anyone trying to design a GIS interface for the non-expert has to invent their own principles which are doomed to be confusing (an nice example would be Google's 'My Maps' or Bing Maps' 'My Places')


One of the biggest challenges to Web-based GIS development is how the data is delivered and how much efficiency I can get out of delivering the data a certain way. The biggest hurdle is that it is very hard to write code for something that requires a human to tweak. Very rarely do you see generalization techniques for vector data used at large scales. Most times you have to tweak the scale ranges to turn on and off the layers.


This question came up on my google search for challenges in GIS, and I feel like contributing here.

Another link that I felt relevant was this paper.

Summarizing what is said there and my own views, I think the biggest challenges (in no particular order are):

  • User Interface: With the host of user interface options, it is challenging for the developer to optimize the offering so as to suit all the devices. Touch based vs desktop vs wearable. The idea of DE as presented by Gore, which features a wearable headset with display, gloves with direction control and speech recognition is a fancy future.
  • Standardization: With standards for data storage and retrieval, we could have geo-databases that rest in the cloud and allow information fetching on the run so that a GIS browse and use can be made smooth.
  • Data Use: Decision makers are always pressed for time. If a tool is to help them, it should do it in a smooth, easy and quick way. GIS seems not to have delivered on this front and that is one of the reasons why it is still not a buzzword.
  • Data: The data is varied, scattered and noisy. Even for organizations with clear incentives on a real-time GIS, the aggregation of data is a hurdle still to big to envision entry.
  • Coordinated Effort: GIS is multi-disciplinary. Every kid knows that. Management is made aware of that in the first slide. Though such multi-disciplinary, multi-departmental projects are rare.

When it comes to coding, I feel I waste far too much time on workarounds. For projections it took me a couple of months to understand the processes and math as there is in my opinion little helpful published material on the subject. The EPSG and OGC documents on the subject did help me get my head around it after a few reads, even though they sometimes seem to be copies of each other. The largest problem I have though as an independent developer is that I can't help but trip over people needing specialized work for medical, industrial, or even simple web app development, even now. With the GIS industry it seems nearly impossible to find a way to enter into the market.


I'm a complete beginner at GIS technologies, figuring things out as I go. And since I have limited funds, I'm trying avoid using any ESRI products and do things entirely with open source tools.

So that said, the hardest things for me so far have all been related to collecting data. There plenty of articles on manipulating and displaying the data, and plenty of tools to make your life easier. But I'm sill walking in the dark when it comes to collecting data.

I have no idea what the professionals do to find and collect data. Something tells me there's an easier way to get data than data.gov and google.

  • Most we have had to buy it from Vendors, who do actual ground surveys and conversion from other sources. In the third world, getting data openly from the Government is a PITA Commented Aug 13, 2010 at 2:28

the GIS world is being expanded toward the common user unless early years where the GIS was only treated by engineers, architecs or the scientific community. In the case the GIS app is done for the common user the challenge is mix appropriately of technologies where the GIS is treated as an technology more(in this case a developer with a little understanding of GIS technology is enough). However in the case that the app is done for the specialized community the challenge is more complex becuase besides joining technologies is necessary to search existing algorithms to fulfill with the requeriments otherwise even worse we would have to development these algorithms. In this case a blend of engineer and developer is the worker appropiated.


You might be unfortunate to be forced to work with GIS analysts that have been converted into software developers.

It's easy to expect a competent software developer to pick up GIS concepts, and let them go through the API and generally figure things out without much help. The same does not hold true of taking a GIS analyst and expecting them to pick up software development.

The results are embarrassing, at best. If you have experience working with bad developers, then imagine it's worse code than anything the worst programmer has developed.

There are some companies you may work for that don't get that.

  • 2
    @emptyset: I'm a geographer who becomed a developer. I don't think my results are "embarassing" at best. I have a lot more development skills then other colleagues that have a IT background - incluind better understanding and USE of OOP concepts, database concepts and rules, etc. Of course, I disagree with your answer :P Commented Jul 22, 2010 at 19:36
  • 1
    @George: And I'm not saying you had said otherwise, just pointing out that to be a great developer you have to know how much you suck. At least I try to.
    – Vinko Vrsalovic
    Commented Jul 22, 2010 at 20:20
  • 2
    +1 On numerous occasions I've been asked to "just fix the bugs" in a Big Ball of Mud en.wikipedia.org/wiki/Big_ball_of_mud written by one or more analysts. Some of the worst code was written by some of the smartest analysts. Often the smart ones fail to appreciate the beauty of simplicity. Often the fault is with management - the analyst may realize the value of refactoring, but cannot justify spending time changing code that is not broken. Commented Jul 23, 2010 at 18:23
  • 3
    For the corollary, you might be unfortunate enough to work with software developers being forced to work as GIS professionals. I am very wary of anyone, from any field, just figuring things out as they go in GIS. I'm an analyst exploring development, and I fully expect -- and want -- people to be wary of my code. Any developer who feels they're doing just fine in GIS, probably isn't. :-) Commented Jul 23, 2010 at 23:17
  • 3
    -1 - very sweeping statement that is provably false and somewhat offensive. As Matt W implies above, you're generally better having a GIS person coming to coding than the other way around because there are so many more resource to help you learn coding and implement best practices than there are in GIS
    – dmbrubac
    Commented Aug 13, 2010 at 15:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.