It sounds like you are not aware of incremental searching. Just click on any place and start typing it will take you directly to that part in the index. There is no need to scroll. We have a blog article that explains this - http://blog.rootsmagic.com/?p=2050
Renee,
Thank you for the quick reply. I am sorry for such a delayed response on my part. I always forget how to launch and access the forums.
I am aware of incremental searching. It works when typing in a Place Name in an ancestor's Edit Person page and in the Place List among other areas. I have utilized it in Place List to create a starting point on a particular letter of the alphabet.
I know realize my suggestion for the Place List Place Name filtering may not have been explained fully and to some degree may have been misdirected, yet there is something of how the Place List re-sorts and presents the very first entry (or the edited entry) after making an edit, rather than staying where the last edit occurred. This "jumping" seems undesirable to me. For example: if I edit an entry such as “of, Chrlstn, S. C.” to the standardized and GeoCode recognized place of “Charleston, South Carolina, United States”, then when the edit is complete the list repopulates to the Place List location of “Charleston, South Carolina, United States” location in the list rather than to the next incorrect “of, xyz place”. This occurs when I attempt to edit (standardize & GeoCode) a Place Name which is with leading “of”, “<” or apostrophe’s to include a county name, or after an edit of a very poorly spelled abbreviation. If there are other “Charleston…” entries this is a good thing, so then I can merge all of them, yet I often find there are several “of, Charleston…” entries and have to go back to that location in the Place List. If not I still have to retype the “of, …” to restart where I left off, unless I merge all the similar “bad” entries together first (which sometimes is not wise to do, especially if there are Place Details –based on previous experience). Most of these issues can be overlooked by using the Data Clean’s Place Clean.
This Incremental Search feature, however, does not seem to be available in the Data Clean's Place Clean (as well I do not believe it to work in Name Clean).
It is in the Data Clean where I would suggest such a limiting alphanumeric search criteria that populates a minimized list feature should be added. Incremental Searching, although it would also be useful here, simply will not suffice. The utilization of Incremental Searching with Select All feature in an extensive Place List is simply not useful without some restrictive criteria. I simply cannot see how those two would work together without an additional “only select matching records to [user entry]”. This then goes back to having an alphanumeric search to populate a minimized list based on the desired alphanumeric character (or string of characters).
My suggestion is to create a search response in Data Clean whereas only those items in the alphanumeric segmented response list show up which would allow the patron/user to edit an individual alphanumeric section of the Place List at a time rather than having to individually check off each and every Original Place Name that is desired to be edited. Granted we have the Select All feature in Data Clean, which is great, but is not easily utilized when the database of Places is several thousand entries of botched up Place Names. I say this due to it being nearly impossible to correct All places in the same sitting, say an afternoon, then Tab down (arrow down) the entries to see which ones we would prefer to deselect (not accept suggested edit). To some degree, my suggestion is more of a time saving suggestion. If within Data clean we had the option of selecting the letter "x" and then Select All (within the limited response to Place Names which begin with the selection of letter "x"), then we might be able to Edit those entries in one sitting. I realize we can do the exact opposite of this by individually selecting one place at a time, yet that has its own drawbacks which i address below.
I suggest this because, in my current databases situation (and with no relief seen in the near future as I import source record Fact details from Family Search), it is a much faster prospect to see the Cleaned Place suggested edit, then deselect those entries which we would not like to edit or interject our own edit. This does come with a catch, whereas a patron might miss a suggested edit which would be incorrect to accept. To remedy this, the just modified Place Clean list could repopulate immediately after Clean Checked Places showing the previously selected results of Clean Checked Places (sorted to only show aforementioned "x" results) in a third column and include a check box option to revert, that is not accept a particular change, that we may have missed. This at least allows for us to review what the Place Changes are one time and correct them before they are finalized. This may seem redundant, yet it is a way to idiot-proof the Place List modifications. Similar screens should be for merging duplicates IMO.
The alternative, and current state, is to individually select each Original Place Name we wish to edit (accept suggested edit or interject our own edit.), then select the check box of the next entry we wish to edit one at a time, or Tab down (arrow down) through the list. Currently this process takes me well over an hour, if not longer, per alphanumeric character. As such I am currently limited to only select one Place at a time as I go through the list.
The current status would be fine if we, as individual product users, either already had a database with a highly standardized Place List or could assure that the other sources we are getting Place Names data from has been "scrubbed" to fall within the standardized methodology. Unfortunately the former is not my current case and the latter is extremely far from the case. The other current option is to manually type in entries in the standardized form into a Edit Person Fact instead of "digitally transferring" them from a source record in Family Search- which makes the digital transfer of Facts (i.e. Place Names) feature useless. I do do both of these methods, individually select within Data clean and Edit as I go when importing sources, occasionally, but it these are extremely tedious and time consuming to do so.
Again, aside from populating a database with correctly and "scrubbed" named places, this suggestion is so that the GeoCoding will associate with a known standard of a location (including historical names) and actually render appropriate maps of the Places in/for a given time frame. The basis for populating a map being a GeoCode location that may have a current and numerous historical names, rather than a current or historical Place Name that is associated to a GeoCoded location.
CountyCheck looks at the time frame for the location and if the county, state or country existed for that event. So I don't see how Place Clean could work like that. There is a CountyCheck report that could help you locate which localities are correct for the time frame of the event.
Geocoding I could see that potentially working inside Place Clean.
I ran the CountyCheck report with default settings...over 6,000 pages in length for my primary RM database.
In the report, I see it offers counties where there is just an abbreviated State such as "Ms."...the result is a long list of Mississippi's counties, per Fact per RM Record (it appears all of the counties - possibly only those which were established on the date if there is a date on the Fact). Most of the time we have no clue what the county or city-township is...that is why we left it with just the state abbreviation, albeit in the example it is an incorrect abbreviation for the state. Other than a rather extensive long list, I see on the first page it does not indicate the RM Record number, although the Family Search record numbers do populate. Nice to have the Family Search numbers, but not helpful to find that exact John Smith in my RM database without the RM record number.
Also the date, which I guess someone approximated rather than indicating "bef" for before or "abt" to indicate about, with a fact offers an entry with
<1739> in Isle of Wight Co, Surrey, Va
Match: Isle of Wight, Surry, Virginia, British North America
Match: Isle of Wight, Surry, Virginia, United States
OK it is only CountyCheck, not County and Nation Check.
Yet other entries seem to only have the British offering when the < and > are not found on pre 1776 entries, but both British and United States are found if the same < and > are used after 1776.
Then there are some with Error presented, yet they do not seem to be consistent.
abt 1691 in of Alton, Hamps., Eng.
Error: Hamps., Eng. is not recognized
31 Mar 1733 in Alton, Hamps., Eng.
Match: Alton, Hampshire, England, Great Britain
OK the "of" before Alton is throwing off the result in the above entry of "Hamps., Eng", which in itself is spelled exactly the same in both, Hampshire is the County though, so confusing.
As well almost all the entries seem to mimic exactly what is already there (I guess this is good?).
Such as:
1871 in Sulphur Springs, Hopkins, Texas, United States
Match: Sulphur Springs, Hopkins, Texas, United States
I would guess the last sample is indicating the CountyCheck match is correct, but needs minor correction? Possibly an extra space on end of it.
Obviously the report will be smaller once I go through Data Clean of Place List.
Not much help to sort through all of those 6000 pages. But I can see it will be useful once my Place Names become more manageable.
.....
I agree that it would seem more likely to utilize GeoCode linking within Data Clean's Place Clean, rather than utilizing CountyCheck to also resolve a GeoCode Location...mainly because CountyCheck only checks the name of a County, so it could not be precise enough to GeoCode a township or city.
As I already suggested back in July, to me it would be ideal to integrate all of the available tools (County Checker, Place List Edit, Place List GeoCode & Data Clean) to work in unison or in series to suggest the current (& historical) standardized Place Name when entering a Place Name in the Edit Person or Add Person forms (also for the historical Place Name for the time period if a date is available in our individual Fact). I realize that such an integrated Place Name resolver would be quite complex - and depending on the data structures of these mentioned tools, might be near impossible in their current data table structures.
Currently, I utilize the tools more or less in the following order when entering a Place Name in the Edit Person (works in a different pattern when entering in the Add Person):
1) Run Gazetteer on the typed or imported text and paste the suggested most likely candidate to Place.
2) Run Place List on Place to set as a standardized place name and to set the GeoCode, if possible.
3) Save the Fact entry which, if a mismatch to CountyCheck, launches the CountyCheck suggestions...modify as needed to satisfy the suggestion -sometimes this takes some investigating as the suggestions are, or do not seem to be, valid or they simply are too vague- usually the case for pre-1850 locations that have changed names several times since (The "Indian Territories" are really unforgiving in this).
4) Save the Fact entry again (because if I do not and the suggested CountyCheck Place Name has not been saved before to the Place List, then it will take me to the top/first entry of the Place List and I will have to bail out to the Edit Person Fact again and save it still), then I copy the Place as suggested by CountyCheck, then go to the seek out the original Place List entry derived in step 2 above (this is tricky as I do not want to overwrite a singular Place Name in use elsewhere) , then paste the CountyCheck Place location to the original Place List Place field, then double checking the Standardized and GeoCoded Place Details remained the same - this is often redoing what step 2 already did, but this time with a "CountyCheck Place Name" in the Place field rather than a matching Place to the current Standardized Place Name.
5) Depending on how step 4 goes, I might have to merge the two entries just created for the Place List.
Unfortunately, this process is not always fail safe as the Standard Place Name sometimes is not discovered in step 2. Occasionally this is due to being an obscure or abandoned location, or a incorrectly spelled Place. For example it took me well over an hour to define the best GeoCode location for one Place location in the British Leeward Islands.
The issue with doing the above, besides being very tedious, is that I almost always have only the historic or partial city-township name of a location which renders some sort of erroneous CountyCheck matching to a Standardized Place Name and GeoCoded location for an entry.
In my opinion, the Place location emphasis is too often placed on the actual source document as being the central point of information, when the reality is the GeoCode for such location is really the only unifying piece of data between past historical and current location Place Names.
.....
As well I realize I could become more educated on utilizing SQLite to manage my RM database. I can and most likely will do this, but my thoughts are for those who might not have the same level of patience and ability to understand how to implement SQLite as a tool to manage their database(s).