Guidance on geographically-related questions belonging on SO vs. GIS.SE

Question

As has already been noted, there are plenty of GIS questions on SO, particularly in r. Some of these questions clearly belong on SO, in that they are asking for programming advice that just happens to relate to geographical data.

More frequently, however, they are asking if functionality that exists in current GIS systems can be performed in R. The most frequent such topics seem to be:

• Mapping/choropleths (e.g. https://stackoverflow.com/questions/13761265/r-colouring-specific-countries-in-a-spatial-polygon )
• Manipulating shapefiles or KML files (e.g. https://stackoverflow.com/questions/7813141/how-to-create-a-kml-file-using-r )

These I believe clearly belong on GIS.SE, although most still remain on SO.

Yet others fall in a grey area. For instance, this question ( https://stackoverflow.com/questions/10212956/subset-spatialpolygonsdataframe ), wherein common GIS functionality is asked for, but the answer uses base R concepts to implement a custom solution. Similarly, this question about cropping required some custom code and arguably some knowledge of S4 methods, but ultimately the question was one about fundamental GIS capabilities.

I hope with this thread we can come to a consensus on what belongs on SO versus what belongs on GIS.SE .

How much programming is required to make it a programming (and thus SO) question? How much geography is required to make it a GIS.SE question?

Answer 1

There's a surprisingly clear distinction between pure programming questions and GIS related questions. Any question that references a GIS platform in an essential way should stay here--it would like be viewed as too specialized on SO. When I see the occasional question here (typically with Python or R code, sometimes VB) that is obviously just about programming, and could be answered by any programmer completely ignorant of GIS, I migrate it to SO.

(I have tended not to migrate Field Calculator questions that are obviously from users struggling with rudiments of Python or VB, on the theory that those users are unlikely to communicate effectively with respondents on SO and that SO readers might not appreciate the distinctions between ESRI/QGIS/etc. field calculations and full-blown code.)

The most troublesome decisions recently have concerned R code. There, I usually have to read through the code to determine whether the trouble is with R itself or, alternatively, with GIS concepts or the use of a GIS-oriented R package. Because SO has a strong R community (they have fielded about 22K questions to date and include some of R's development team), I am inclined to migrate the former questions and leave the latter. The main problem with this policy is that it can take time and effort to make the migration decision. But I think it's worth it, because I see great value in accumulating a corpus of R-based GIS solutions on this site, due to R's potential to provide an open-source GIS analysis platform that is more powerful and flexible than anything else out there.

In response to another answer here, I need to emphasize that you should not cross-post questions! SE policy strongly discourages that. It creates confusing duplication and is time-consuming to rectify, requiring communications among moderators of multiple sites, migration, editing, and merging.

Answer 2

I Don't think that this problem can be solved or whether we can reach a 'consensus on what belongs on SO versus what belongs on GIS.SE'.

The problem of overlap amongst many of the Stack exchange sites is an old complaint, and has been discussed hundreds of times on meta.so

It has to do a lot with the background of the person asking the question. For example, many web developers started using the Google Maps API without having any background in GIS. And naturally they asked questions on SO. There are more questions tagged Google Maps API on SO, than GIS.se.

Does that mean that these questions belong here? I am not so sure of that. Most of the members of GIS.se are experienced with ESRI and OSGeo software, and not specifically with the intricacies of the Google Maps API. But you'll find lots of answers on this topic on SO.

I think that at the end of the day, we need to ask for each question, whether there is a better home for it, which has members experienced in the topic.

It also has to do with the community already present as well as the attitude with which the question was asked. For example, there are many questions tagged with esri both stackoverflow and serverfault. If you look at them, you will see that most of them have one or two answers and very few views. If those same questions were asked her, I'm quite sure that you would get a better response on most of them.

Then there are question, which are best suited to our sister sites, even if they have to do with gis software. For example this one

So In short, there will always be an overlap, and you can always cross post the question, provided you have tailored it to the audience of that particular stack-exchange site.

Answer 3

The existing answers are excellent. I would only add that, some time ago now, I flagged for migration and commented a number of questions on SO which I thought would be better served here and received pretty much a non-response; none migrated anyway.

Now my strategy is that whenever I bump into a GIS question elsewhere in the network (not really that often) I look for an existing pertinent answer here to link back to. The knowledge base is big enough now there is often something.

Answer 4

Firstly you need to define Geography - that alone is a wide field. Geography typically encompasses Geomatics http://en.wikipedia.org/wiki/Geomatics. Here GIS SE accepts many wide-ranging questions including programming like python, some questions are more about the process or code that the GIS factor.

An Example is Improving Python script processing speed (performance)?

Technically this is not a pure GIS.SE question - but there are many in our community that can answer this question. But when answered it does provide value to this community.