Spell Checking ArcGIS
Posted 02 January 2013 - 07:10 PM
Posted 03 January 2013 - 12:29 AM
Is there some way for spell checking in ArcGIS 10.1? I did a Google search and found Map speller which is a ESRI business partner and offers a spell checker for $450 for a single license (which may explain why a spell checker is notably absent from ArcGIS). Is there an alternative though?
Is there a way to export all text from ArcGIS to say a Word document, or even a flat text file? If so, you could simply run it through Word's spell check.
Email: email@example.com / Twitter: @redgeographics
Posted 04 January 2013 - 09:31 AM
Posted 04 January 2013 - 02:00 PM
Needless to say, no general-purpose spellchecker will know to correct Spilt to Split, that Union Station is more likely than Onion Station, whether a road is named for Regan or Reagan, nor whether the local preference is for Sauk Centre or Sauk Center.
Posted 04 January 2013 - 11:10 PM
When confronted with odd or disputed words I refer to the various Geographic Names Boards in Australia which provide a definitive and legal name and spelling which is quite useful in dealing with the nit pickers.
However on a project I was working on I had misspelled stanchion as stauncion - the spell checker in Word picked it up in the body of the report and it was easily fixed but in ArcGIS I had to do it manually all - 16 of them hence my interest in a spell checker.
Posted 07 January 2013 - 09:55 AM
That's what I was trying to explain about MapSpeller. You can add your own place names so that it checks them against your own list - then it will correct them all at once.
Just FYI - I have no association with the product!
Posted 18 March 2013 - 09:43 AM
Hello everyone and thanks Karas (we should meet!).
I am the guy Karas is talking about and who has spent over 10 years developing MapSpeller for ArcGIS.
The reason why a lower-cost spell-checker doesn't exist is that spell-checking ArcMap is significantly more complex than proofing other types of documents (emails, etc.) and only a small fraction of ArcMap users are willing to pay even the smallest amount for one. This is perfectly illustrated in the comments made elsewhere in this post. In addition, some also think that accurately proofing maps is just not possible. It's a bad combination for everybody and may at least partly explain why Esri hasn't developed one in its 40+ years of existence.
Well, not only do I have a patent for having solved some of those issues, but I have developed the program that does it. So, here are my 2 cents!
ArcGIS 9 had a VBA sample script (as pointed out) that sent the text of selected map and layout annotations to the MS Word spell-checker (assuming it was present on the PC). It worked in limited ways but had significant structural flaws.
Not the least of those flaws is: what's the point in proofing only map and layout annotations if you are going to leave typos in legends, grouped graphics, layer labels, geodatabase annotations, dynamic text, map annotations, scale bars and scale text objects, etc.? The sample script was not able to send the text from these objects to the MS Office spell-checker. If I remember correctly, you weren't able to zoom in and pan around each potential error to figure out how to handle it either. You may think that the answer to the question is that you'll have fewer typos! But I would argue that it would unlikely be so! it just gives a false sense of confidence, which in turn increases the likelihood of leaving more typos in those other objects.
Why not proofing manually? That's not a bad idea but it's very tedious (think thousands of records/labels) and time consuming (time is money!). So to be realistic, it can only be done to supplement an automated method. I would suggest that you read the article that was recently published in the Winter 2012-2013 issue of the Esri ArcNews magazine and titled "Dodging Cartography's Great Nemesis" at http://www.esri.com/...graphys-nemesis.
Secondly, MS Office had significant shortcomings, not because it's not a good spell-checker, but because it was developed without geography and ArcGIS in mind. It was never intended for spell-checking ArcMap. Before focusing on what that means, I want to point out that the sample script requires VBA, which has been deprecated at ArcGIS 10.1. R.I.P.! Also, it never understood ArcMap format tags, or worse, dynamic text tags within annotations. Those latter tags point to text actually not stored in the annotations themselves so this text would be missed entirely and tags would show in the MS spell-checker, creating a potential for breaking the syntax.
Several map producers use Adobe Illustrator or Photoshop to proof PDF documents that they generate from ArcMap. Those two software products suffer from the same shortcomings as MS Office, plus they won't even correct the original ArcMap document (mxd) or databases. So, the same errors are constantly being "re-discovered" as never fixed in ArcMap.
MS Excel and Access have similar flaws when it comes to proofing GIS tables, and they can only proof tables in a very limited number of formats, without ArcMap tags and without providing any visual feedback via a map to help determine how to handle potential errors. In some cases, they can end up corrupting feature classes too because they are not aware that tables may be part of feature classes and of relationship classes!
Now onto what a GIS spell-checker should do. Well, read the previous comments on this post: be culturally aware (Australian versus American English, for ex.), be customizable for a specific industry or discipline, be able to spell-check geographically, be able to detect "dangerous" word substitutions (Union/Onion, soldier/solider, public/pubic, etc.), be able to easily replace all occurrences of the same misspelling regardless of type of object that contains it (annotations, grouped graphics, any database supported by ArcMap, etc.). What else? If you work with international maps, wouldn't you want a spell-checker that simultaneously proofs maps and databases (including name places) in the language of the intended reader but also of the local culture(s)? For example the city of Brussels (English) is called/spelled Bruxelles in French and Brussel in Dutch/Flemish, which are both official local languages. If not, you would end up seeing correctly spelled words in one language show up as errors when proofing in another language.
At the risk of sounding commercial, MapSpeller does all that. Some of those methods are patented, such as the use of spatial dictionaries which are implemented as polygon feature classes where each feature is a dictionary word with a minimal area of validity delineated by its polygon. Spatial dictionaries (Locationaries ) can be derived from existing gazetteers like the GNIS mentioned elsewhere in the post. Currently, customers have to build their own from scratch or as they go (or hire Edgetech to do so), but the plans are to eventually offer many as online map services. With Locationaries, the MapSpeller software can geographically segregate among name places or other geographically bound words, which conventional spell-checkers can't do. You can read more about it www.MapSpeller.com. Try it for 90-days. Be the judge.
Typographic or positional errors don't just impact maps and databases, they impact the results of analyses as well, for example by not joining records that should have joined. In all situations, they impact the credibility of the document, the GIS professional and his/her organization and message.
So, in conclusion, when searching for a spell-checker, forget that many non-GIS software products come with one. Although I can't speak for Esri, I have been told by executives there for years and still recently that it's not developing one. Esri decided to rely on its partners to offer this functionality. Regardless, focus on the value that a proper spell-checker brings to your organization instead. How much does it cost you in time to proof and correct your maps and databases? In reprints? In delays? How confident are you that you haven't interchanged two name places or that your work won't be affected by textual errors? What's the cost to your reliability, credibility or professionalism if you leave such errors on your maps, in your databases, or if they had you recommend incorrect solutions to analyses? What's the cost of a spell-checker compared to the huge cost of building your GIS system?
Yet, paper or web maps are what the world sees and how it judges your whole system.
Remember the Apple debacle several months ago when it dropped Google maps from its iPhone, IPads, etc. for a lesser-quality geodatabase? Apple's stock is now at two thirds of its peak while the market overall is breaking record highs. While I don't know how much can be attributed directly to the debacle, the latter certainly broke the sense of infallibility that existed around the company at the time. That was priceless; so is your reputation.
On a personal note, as a GIS professional, I never thought I would spend so much time on spell-checking, but it's really interesting to bring geography to spell-checking, and spell-checking to GIS.
Edited by Roose, 26 April 2013 - 09:01 AM.
Posted 18 March 2013 - 10:08 PM
If I could spell correctly 100% of the time I wouldnt need a spell checker and manually checking would be pointless but I cannot and manual proofing is a hassle becuase its the words you think are right or dont know are wrong that are the critical ones.
I would have thought that ESRI would have implemented a spell checker from day one.
Posted 11 April 2013 - 08:03 PM
FYI, MapSpeller can now be licensed on a yearly basis... lowering the upfront cost.
Posted 26 April 2013 - 09:08 AM
I just came across this very interesting video on the Agile development philosophy (which Esri is following): .
The answer to why Esri hasn't developed an ArcMap spell-checker is somewhere in there!
It's an interesting video even if you are not a software developer as it illustrates why some software ideas get implemented and others are not, or get postponed.
Edited by Roose, 26 April 2013 - 09:08 AM.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users