diff --git a/2022_005_goldberg_v1_1/Skripte/main.py b/2022_005_goldberg_v1_1/Skripte/main.py
new file mode 100644
index 0000000000000000000000000000000000000000..6f26d448a148d6bca6cde05ad7cc58b123f49a52
--- /dev/null
+++ b/2022_005_goldberg_v1_1/Skripte/main.py
@@ -0,0 +1,291 @@
+import qualitychecker
+import placefinder
+import provincefinder
+import csv
+import os.path
+from multiprocessing import Pool, current_process
+from functools import partial
+import time
+from zeep import Client
+import json
+
+
+def importMiniGOV():
+ """
+ This function loads the Mini-GOV that is located in the data folder.
+ This is used to assign a location to a standard notation.
+ :return: list of Mini-GOV entries
+ """
+ # Information from http://wiki-de.genealogy.net/GOV/Mini-GOV, 23.03.2020
+ # german language designation, because those in the Mini-GOV are also in German language
+ miniGOVHeaders = ["GOV-Kennung", "Objekttyp als Text", "Objekttyp als Zahl", "aktueller Name",
+ "letzter deutscher Name", "Staat", "adm. Zuordnung 1", "adm. Zuordnung 2", "adm. Zuordnung 3",
+ "adm. Zuordnung 4", "Postleitzahl", "geographische Breite", "geographische Länge"]
+
+ # embedding the Mini-GOVs of different countries (Germany, Poland, Austria, Switzerland, Czech Republic, Denmark, France, Netherlands)
+ miniGOVFiles = ["gov-data_D_20190325_201241.txt", "gov-data_PL_20190325_201241.txt",
+ "gov-data_A_20190325_201241.txt", "gov-data_CH.txt", "gov-data_CZ_20190325_201241.txt",
+ "gov-data_DK.txt", "gov-data_F_20190325_201241.txt", "gov-data_NL.txt"]
+
+ miniGOV = [] # initialize list with entries of Mini-GOV
+ # for each named Mini-GOV file the data is loaded and merged into miniGOV
+ for i in miniGOVFiles:
+ filepath = os.path.join("data", i)
+ with open(filepath, encoding="utf-8") as csvfile:
+ reader = csv.DictReader(csvfile, delimiter="\t", fieldnames=miniGOVHeaders)
+ miniGOV = miniGOV + list(reader)
+ csvfile.close()
+
+ # expand of miniGOV because some Mini-GOVs contain "previous german names"
+ # for each former German name an entry is also created so that it can be found
+ expandMiniGOV = [] # initialize
+ for i in miniGOV:
+ if i["letzter deutscher Name"] != "":
+ i["aktueller Name"] = i["letzter deutscher Name"] # overwrite the current name with the last german name
+ else:
+ continue; # do not append
+ expandMiniGOV.append(i)
+
+ # merge miniGOV and expandMiniGOV
+ miniGOV = miniGOV + expandMiniGOV
+
+ # alphabetical sorting of miniGOV in relation to the column with the name of the place
+ # all designations are written in lower case
+ # .lower() is extremely important here, because otherwise capital letters are preferred over small ones and such cases occur in the GOV (e.g. some places starting with IJ, IJselstein)
+ miniGOV = (sorted(miniGOV, key=lambda x: (x["aktueller Name"].lower())))
+ return (miniGOV)
+
+
+def loadData(filename, delimiter, encoding):
+ """
+ This function opens files in which data is temporarily stored and was created by the program in a previous run.
+ :param filenname: name of the file
+ :param delimiter: string of delimiter
+ :return: content of the file as a list of lists; if no file exists an empty list
+ """
+ emptyList = [] # list oft dicts
+ try:
+ with open(filename, "r", encoding=encoding) as data:
+ for i in csv.DictReader(data, delimiter=delimiter):
+ i = json.loads(json.dumps(i))
+ emptyList.append(i)
+ except FileNotFoundError:
+ print("Status: Initial run, do not create a list yet:", filename)
+ return (emptyList)
+
+
+def appendFile(filename, data, fieldnames, moreThanOneRow):
+ """
+ This function adds a line to an existing file.
+ :param filename: name of the file
+ :param data: content of the line to be added
+ :param fieldnames: column headers of the file
+ :param moreThanOneRow: if it equals 0 so one row are printed or equals 1 more row are printed (integer)
+ """
+ openQualityChecker = open(filename, "a", newline="", encoding="utf-8")
+ writerQualityChecker = csv.DictWriter(openQualityChecker, fieldnames=fieldnames, delimiter="\t")
+ # distinction between adding data to "quality.csv" file and other files
+ # with "quality.csv" only one row is added, with all others several rows
+ if moreThanOneRow == 0:
+ writerQualityChecker.writerow(data)
+ else:
+ writerQualityChecker.writerows(data)
+ openQualityChecker.close()
+
+
+def createFile(filename, fieldnames, delimiter, encoding):
+ """
+ This function is used to create files if they do not yet exist.
+ But if they already exist, the existing content will be loaded.
+ :param filename: name of the file
+ :param fieldnames: column headers of the file
+ :return: loaded data; if there is no data, an empty list is returned
+ """
+ # load existing content
+ loadedData = loadData(filename, delimiter, encoding)
+ # create a new file if it is not there
+ if len(loadedData) == 0: # only if loadedData is an empty list a new file is created
+ openQualityChecker = open(filename, "w", newline="", encoding="utf-8")
+ writerQualityChecker = csv.writer(openQualityChecker, delimiter=delimiter)
+ writerQualityChecker.writerow(fieldnames)
+ openQualityChecker.close()
+ return (loadedData)
+
+
+def loadGedcomFile(datename):
+ """
+ This function loads the data from a single GEDCOM file.
+ If the sources are not in GEDCOM format, this area must be adjusted.
+ :param datename: name of source (here GEDCOM file)
+ :return: list containing one entry per line of a GEDCOM file; if the file cannot be found "NONE" is returned
+ """
+ filepath = os.path.join("data", datename)
+ line = [] # initialize empty list
+ try:
+ gedcom = open(filepath, "r", encoding="utf-8")
+ data = gedcom.readline()
+ # delete the last character of each line, which is a space
+ data = data[:-1]
+ # the last line is empty, so the lines are processed until this empty line appears
+ while data != "":
+ data = str(gedcom.readline())
+ data = data[:-1]
+ line.append(data)
+ gedcom.close()
+ return (line)
+ except FileNotFoundError:
+ print("Error: Problem with access to file", datename, ".")
+ return ("NONE")
+
+
+def parallel(filename, miniGovList, qualityDict, fieldnamesStep1, fieldnamesStep2, fieldnamesStep3, filenameStep1,
+ filenameStep2, filenameStep3):
+ """
+ This function is called once per source (here GEDCOM file).
+ The process consists of three steps.
+ First, a metadata analysis is performed, the result of which can be found in the file "quality.csv".
+ Then the urban names are subjected to identification.
+ In the third step, regional clustering is performed at a defined time.
+ The goal is to extend the files "quality.csv", "placefinder.csv" and "provincesdict.csv".
+ :param filename: name of the file/source
+ :param miniGovList: list of merged entries of the Mini-GOV
+ :param qualityDict: Metadata about the data from previous program runs
+ :param fieldnamesStep1: name of the columns of the file "quality.csv"
+ :param fieldnamesStep2: name of the columns of the file "placefinder.csv"
+ :param fieldnamesStep3: name of the columns of the file "provincesdict.csv"
+ :param filenameStep1: string of the file name "quality.csv"
+ :param filenameStep2: string of the file name "placefinder.csv"
+ :param filenameStep3: string of the file name "provincesdict.csv"
+ """
+ # a loop with one iteration is used here to formulate a termination condition
+ for i in range(1):
+ # note the number of the parallelization process
+ spawnPoolWorker = current_process().name
+
+ # load data of a GEDCOM file
+ # must be changed if source is not a GEDCOM file
+ data = loadGedcomFile(filename)
+
+ # Step 1: Metadata/Quality analysis
+ print(spawnPoolWorker, "Status: Metadata analysis of", filename, "begins.")
+ resultQualityChecker = qualitychecker.mainMetadataInspector(data, filename, miniGovList, qualityDict)
+ if resultQualityChecker == "StartingExitStrategy":
+ print(spawnPoolWorker, "Status: The data to file", filename, "is complete.")
+ continue # check next file
+
+ # Step 2: Identification
+ print(spawnPoolWorker, "Status: Identifying the places of", filename, "begins.")
+ resultPlaceFinder = placefinder.mainPlaceFinder(data, resultQualityChecker, filename, miniGovList)
+
+ # Step 3: Clustering
+ print(spawnPoolWorker, "Status: Clustering of the places of", filename, "begins.")
+ # definition of a year at which the administrative clustering should take place
+ referencetime = 1800
+ # a working internet connection is necessary
+ client = Client("https://gov.genealogy.net/services/ComplexService?wsdl")
+ resultProvinceFinder = provincefinder.mainProvinceFinder(resultPlaceFinder, filename, client, referencetime)
+
+ # blocked file extension
+ # happens because if an output is included, all files are still at the same file level
+ try:
+ appendFile(filenameStep1, resultQualityChecker, fieldnamesStep1, 0) # only one row
+ appendFile(filenameStep2, resultPlaceFinder, fieldnamesStep2, 1)
+ appendFile(filenameStep3, resultProvinceFinder, fieldnamesStep3, 1)
+ except:
+ print("Error: Blocked printing of lines failed. Manual deletion of the last entries in the files attached.")
+
+
+if __name__ == "__main__":
+ """
+ This construction exists to prepare the parallelization.
+ The section up to the comment "start of parallelization" is executed only once.
+ It is used to load the location data from the source (here GEDCOM files) and create CSV files initially.
+ """
+ # memorizing the start time
+ starttime = time.perf_counter()
+
+ # define range of GEDCOM data
+ # assume that the GEDCOM files are in 12345.ged format
+ begin = 0 # starts at 0.ged
+ end = 60000 # ends at 60000
+ gedcomNamesList = [] # creation of a list with possible GEDCOM file names
+ while begin != end:
+ datename = str(begin) + ".ged" # name of GEDCOM file
+ gedcomNamesList.append(datename)
+ begin = begin + 1
+
+ # possibility that not all files of the gedcomNamesList exist
+ # do not let the non-existent files into the multiprocessing
+ # check the existence of the files
+ gedcomNamesListClear = [] # version of gedcomNamesList, which contains only existing files
+ for i in gedcomNamesList:
+ filepath = os.path.join("data", i) # GEDCOM files are located in the subfolder "data"
+ try:
+ gedcom = open(filepath, "r", encoding="utf-8")
+ gedcom.close()
+ gedcomNamesListClear.append(i)
+ except FileNotFoundError:
+ pass
+
+ # Loading data from the Mini-GOV
+ miniGovList = importMiniGOV()
+
+ # initialization of CSV files, which are needed in the further course
+ filenameStep1 = "quality.csv"
+ fieldnamesStep1 = ["filename", # name of GEDCOM file
+ "number of places",
+ "number of noHit",
+ "number of moreThanOneHit",
+ "number of definitely coordinates",
+ "longitude mean of of definitely coordinates",
+ "latitude mean of of definitely coordinates",
+ "number of existing clusters",
+ "number of relevant clusters",
+ "cluster midpoints" # list of lists of geographical centers of individual clusters
+ ]
+ # load already existing data into a variable
+ qualityDict = createFile(filenameStep1, fieldnamesStep1, "\t", "utf-8")
+
+ # list of all Urbanoyme per source
+ filenameStep2 = "placefinder.csv"
+ fieldnamesStep2 = ["id", # GOV-ID of a place
+ "latitude", # latitude of the place
+ "longitude", # longitude of the place
+ "selection information", # description of the identification of this urbanonym
+ "adjusted name", # adjusted spelling of the urbanonym in the source
+ "original name", # original spelling of the urbanonym in the source
+ "filename" # name of the file where the urbanonym is found
+ ]
+ createFile(filenameStep2, fieldnamesStep2, "\t", "utf-8")
+
+ # list of urban names already assigned to a province per file to avoid double searches
+ filenameStep3 = "provincesdict.csv"
+ fieldnamesStep3 = ["original name", # original spelling of the urbanonym in the source
+ "filename", # name of the file where the urbanonym is found
+ "id", # GOV-ID of a place
+ "province" # name of assigned administrative unit
+ ]
+ createFile(filenameStep3, fieldnamesStep3, "\t", "utf-8")
+
+ # start of parallelization
+ # executes the function "parallel" per entry in the list gedcomNamesListClear (per urbanonym)
+ # parallelization is realized to shorten the processing time
+ pool = Pool()
+ pool.map(partial(parallel,
+ miniGovList=miniGovList,
+ qualityDict=qualityDict,
+ fieldnamesStep1=fieldnamesStep1,
+ fieldnamesStep2=fieldnamesStep2,
+ fieldnamesStep3=fieldnamesStep3,
+ filenameStep1=filenameStep1,
+ filenameStep2=filenameStep2,
+ filenameStep3=filenameStep3, )
+ , gedcomNamesListClear)
+ pool.close()
+ pool.join()
+
+ # memorizing the time of finishing
+ finishtime = time.perf_counter()
+
+ # print the duration of the program run
+ print("Finished in", round(finishtime - starttime, 2), "seconds(s)")
diff --git a/2022_005_goldberg_v1_1/Skripte/placefinder.py b/2022_005_goldberg_v1_1/Skripte/placefinder.py
new file mode 100644
index 0000000000000000000000000000000000000000..1260b6c37fe4e3bc8ecaf1ec37f4ae9b0955b8d5
--- /dev/null
+++ b/2022_005_goldberg_v1_1/Skripte/placefinder.py
@@ -0,0 +1,693 @@
+from Levenshtein import distance
+from haversine import haversine
+import copy
+import qualitychecker
+
+
+def placeFinder(locNameClean, miniGOV, gedcomMetaInfos, bannedObjectTypes):
+ """
+ This function prepares urban names for identification.
+ :param locNameClean: name of place after cleansing
+ :param miniGOV: list of all objects in the Mini-GOV
+ :param gedcomMetaInfos: content for one line of the file "quality.csv"
+ :param bannedObjectTypes: list of banned object types
+ :return: list of GOV identifier, longitude, latitude, and information about identification process
+ """
+ # searching in with row of gedcomMetaInfos the information to the actual file is in
+ clusterMeanList = gedcomMetaInfos["cluster midpoints"]
+
+ # initiate find() to return some values of parameter of the seltected object
+ resultOfFind = find(miniGOV, locNameClean, clusterMeanList, bannedObjectTypes)
+ positionMiniGOV = resultOfFind[0] # number of row of selected object in Mini-GOV
+ selectInfo = resultOfFind[1] # information about the way of selecting/identifiying object
+ # if find() was not successfull then selectedRowOfMiniGOV is -1 and parameter should named with "NONE"
+ if positionMiniGOV != -1:
+ govid = miniGOV[positionMiniGOV]["GOV-Kennung"] # ID of GOV object
+ longitude = miniGOV[positionMiniGOV]["geographische Länge"] # longitude
+ latitude = miniGOV[positionMiniGOV]["geographische Breite"] # latitude
+ return [govid, longitude, latitude, selectInfo]
+ govid = "NONE"
+ longitude = "NONE"
+ latitude = "NONE"
+ return [govid, longitude, latitude, selectInfo]
+
+
+def find(miniGOV, locNameClean, clusterMeanList, bannedObjectTypes):
+ """
+ This function identifies an adjusted urbanonym.
+ :param miniGOV: list of all objects in the Mini-GOV
+ :param locNameClean: name of place/urbanonym after cleansing
+ :param clusterMeanList: list of means of coordinates for the clusters in a source
+ :param bannedObjectTypes: list of banned object types
+ :return: index of the line in "miniGOV" of the identified location and information about the type of identification
+ """
+ # headline of the column with the relevant information (acutal name) ob objects
+ keyMiniGOV = "aktueller Name"
+
+ # banned characteristics of value
+ if locNameClean == "unrealisticSequenceOfStringsAlpha":
+ selectInfo = "Not selected on the basis of prohibited content."
+ return ([-1, selectInfo])
+ elif locNameClean == "unrealisticSequenceOfStringsBeta":
+ selectInfo = "Not selected based on prohibited specification."
+ return ([-1, selectInfo])
+
+ # define rank order of some types (priority)
+ # if there are several matches, it is more likely to be a "Stadt" (more urban) than a "Ort" (more rural)
+ orderRankObjectTypes = ["Kreisfreie Stadt",
+ "Stadt",
+ "Dorf",
+ "Pfarrdorf",
+ "Ort",
+ "Ortsteil",
+ "Ortschaft",
+ "Wohnplatz",
+ "Weiler"]
+
+ # cleaned location data can contain several urbanonyms (z. e.g. places in brackets, hyphen as separation)
+ # these must be checked individually if one of them cannot be identified
+ # "valueList" contains all sub-urbanonyms to be examined and starts with the entire cleaned-up designation
+ valueList = [locNameClean]
+ # search for hyphens
+ if "-" in locNameClean:
+ positionMinus = locNameClean.find("-")
+ # first add what comes before the hyphen
+ valueList.append(locNameClean[:positionMinus])
+ valueList.append(locNameClean[positionMinus + 1:])
+ # search for brackets
+ if "(" in locNameClean and ")" in locNameClean:
+ positionBreakedOpen = locNameClean.find("(")
+ positionBreakedClose = locNameClean.find(")")
+ # first add what is not in brackets
+ # assumption: the brackets are not in front and have a space before (therefore -1)
+ valueList.append(locNameClean[:positionBreakedOpen - 1])
+ valueList.append(locNameClean[positionBreakedOpen + 1:positionBreakedClose])
+ # if no indication of it can be identified, then check the part up to the first space
+ if " " in locNameClean:
+ positionSpace = locNameClean.find(" ")
+ valueList.append(locNameClean[:positionSpace])
+
+ # testing of the different urbanonym components
+ # if anything can be identified, the loop is terminated and not all loop passes are needed
+ for counter, newLocValueClean in enumerate(valueList):
+ # first, the unadjusted urbanonym checks the information before the comma
+ # binary search algorithm begins here
+ position = int(len(miniGOV) / 2) # start in the middle of the Mini-GOV
+ # initial not 0, because otherwise it leads to complex numbers
+ furtherPosition = len(miniGOV)
+ # execute loop until the new position is only 10 lines away from the old one
+ while (furtherPosition - position) not in range(-10, 10):
+ positionCache = position
+ # designation from the Mini-GOV must be converted to lower case
+ if newLocValueClean > miniGOV[position][keyMiniGOV].lower():
+ # amount of difference between "furtherPosition" and "position" / 2
+ position = position + int(abs(furtherPosition - position) / 2)
+ elif newLocValueClean < miniGOV[position][keyMiniGOV].lower():
+ # amount of difference between "furtherPosition" and "position" / 2
+ position = position - int(abs(furtherPosition - position) / 2)
+ elif newLocValueClean == miniGOV[position][keyMiniGOV].lower():
+ break; # runtime improvement, it cannot be more precise
+ furtherPosition = positionCache
+ # search for a match 30 lines before and after the found position; find this positions
+ # looks at the 30 in front and behind, if there are e.g. 60 places with the same name
+ try:
+ miniGOV[position - 30][keyMiniGOV]
+ startPosition = position - 30
+ except IndexError: # the error occurs when the number is in front
+ startPosition = 0
+ try:
+ miniGOV[position + 30][keyMiniGOV]
+ endPosition = position + 30
+ except IndexError: # the error occurs when the number is behind
+ endPosition = len(miniGOV)
+
+ # initialising of lists
+ equalList = [] # values that are equal
+ similarList = [] # values that are similar
+
+ # similarity analysis
+ if newLocValueClean != "": # similarity analysis makes sense, if "newLocValueClean" is not empty
+ # creation of a list with the results
+ simularityList = []
+ # check each position 30 lines before and after the previously found line
+ for i in range(startPosition, endPosition):
+ # use of the levenshtein distance for equality checks
+ levenshteinDistance = distance(miniGOV[i][keyMiniGOV].lower(), newLocValueClean)
+ simularityList.append([i, # index (acutal position in Mini-GOV)
+ levenshteinDistance, # absolute levensthein distance
+ levenshteinDistance / len(newLocValueClean), # relative levenshtein distance
+ miniGOV[i][keyMiniGOV].lower(), # comparative Mini-GOV designation
+ newLocValueClean # comparative urbanonym
+ ])
+ # search for hits where the Levenshtein Distance was 0 (equality)
+ for i in simularityList:
+ # if levenshteinDistance is 0 then both strings are the same
+ position = i[0]
+ levenshteinDistance = i[1]
+ if levenshteinDistance == 0:
+ equalList.append(position) # equalList contains only line numbers
+ # if there is none with the levenshteinDistance 0, then check if there are hits with an relative levvenshtein distance of 0.17
+ if len(equalList) == 0:
+ for i in simularityList:
+ if i[2] <= 0.17:
+ similarList.append(i[0]) # similarList contains only line numbers
+
+ # check length of equalList and similarList
+ # "equalList" has a priority over "similarList"
+ # "selectInfo" explains if and how an identification takes place
+ if len(equalList) == 0:
+ # no same hit but exactly one similar hit
+ if len(similarList) == 1:
+ # even if there is only one hit, it must not have a banned object type
+ if miniGOV[similarList[0]]["Objekttyp als Zahl"] in bannedObjectTypes:
+ selectInfo = "Not selected because nothing was found in the Mini-GOV (with similarity analysis)"
+ return ([-1, selectInfo])
+ else:
+ selectInfo = "Selected based on a single matching hit in the similarity analysis"
+ return ([similarList[0], selectInfo])
+ # no same hit but more then one similar hit
+ elif len(similarList) > 1:
+ # start a selection
+ resultAreaSearch = areaSearch(similarList,
+ "(with similarity analysis)",
+ miniGOV,
+ clusterMeanList,
+ bannedObjectTypes,
+ orderRankObjectTypes)
+ return (resultAreaSearch) # return value has the same structure as the previous
+ # no equal or similar hit
+ # should still be able to do the next cycle and will only return a value if the last element of the "valueList" was checked
+ elif len(similarList) == 0 and (counter + 1) == len(valueList):
+ selectInfo = "Not selected because nothing was found in the Mini-GOV (with similarity analysis)"
+ return ([-1, selectInfo])
+ # exactly one hit in "equalList"
+ elif len(equalList) == 1:
+ selectInfo = "Selected based on a single matching hit"
+ return ([equalList[0], selectInfo])
+ # more then one hits in "equalList"
+ elif len(equalList) > 1:
+ resultAreaSearch = areaSearch(equalList,
+ "",
+ miniGOV,
+ clusterMeanList,
+ bannedObjectTypes,
+ orderRankObjectTypes)
+ return (resultAreaSearch) # return value has the same structure as the previous
+
+ # if nothing is found until here, then return -1
+ selectInfo = "Nothing selected because nothing was found in the Mini-GOV"
+ return ([-1, selectInfo])
+
+
+def areaSearch(similarList, supplementSelectInfo, miniGOV, clusterMeanList, bannedObjectTypes, orderRankObjectTypes):
+ """
+ This function selects one of several possible locations.
+ The basis for this is the distance to the other identified locations in the source.
+ :param similarList: list of line numbers in the Mini-GOV that match the urbanonym
+ :param supplementSelectInfo: text that can be appended to "selectInfo
+ :param miniGOV: list of all objects in the Mini-GOV
+ :param clusterMeanList: list of means of coordinates for the clusters in a source
+ :param bannedObjectTypes: list of banned object types
+ :param orderRankObjectTypes: list that defines rank order of some object types
+ :return: list of selected position and an information about the selection/identification process
+ """
+ # reading coordinates from the Mini-GOV and write them into coordList
+ coordList = []
+ for i in similarList: # i is position in Mini-GOV
+ longitude = miniGOV[i]["geographische Länge"]
+ latitude = miniGOV[i]["geographische Breite"]
+ coordList.append([i, longitude, latitude])
+
+ # calculate similarity of values in "coordList"
+ geoDistanceList = []
+ for i in coordList:
+ # ignore entries without valid coordinates
+ if i[1] != "" and i[1] != "NONE" and i[2] != "" and i[2] != "NONE" and len(clusterMeanList) != 0:
+ # calculate a distance for each cluster center of the source and write it into a list
+ for j in clusterMeanList: # clusterMeanList consists of "cluster midpoints"
+ # latitude coordinate 1, longitude coordinate 1, latitude coordinate 2, longitude coordinate 2
+ distance = haversine((float(i[2]), float(i[1])), (float(j[0]), float(j[1])))
+ geoDistanceList.append([i, distance])
+
+ # determination of the smallest distance
+ minimalDistance = 9999999.999 # some high initial value
+ for i in geoDistanceList:
+ newDistance = i[1] # haversine in 1
+ if newDistance < minimalDistance:
+ minimalDistance = newDistance
+ positionMiniGOV = i[0][0] # line number of the entry in the Mini-GOV that has the smallest distance
+
+ # only one value with coordinates remains
+ # not 1, but 1*cluster, because one is created for each cluster; inequality condition mandatory
+ if len(geoDistanceList) == 1 * len(clusterMeanList) and len(geoDistanceList) != 0:
+ selectInfo = "Selected because it was the only one with coordinates " + supplementSelectInfo
+ # several values remain, but the closest value is selected
+ elif len(geoDistanceList) > 1 * len(clusterMeanList):
+ selectInfo = "Selected on the basis of geographical proximity " + supplementSelectInfo
+ # no distance was determined
+ elif len(geoDistanceList) == 0:
+ # no one with geodistance there, but maybe I can exclude some others via the types
+ # creation of a list in which the unauthorized types are filtered out
+ noGeoDistButAllowedTypeList = []
+ for i in coordList:
+ position = i[0]
+ if miniGOV[position]["Objekttyp als Zahl"] not in bannedObjectTypes:
+ noGeoDistButAllowedTypeList.append(i)
+ # one object remains, chose this
+ if len(noGeoDistButAllowedTypeList) == 1:
+ selectInfo = "Selected based on the only valid type " + supplementSelectInfo
+ positionMiniGOV = noGeoDistButAllowedTypeList[0][0]
+ # no element is left over
+ elif len(noGeoDistButAllowedTypeList) == 0:
+ selectInfo = "None selected, because none has a valid type " + supplementSelectInfo
+ positionMiniGOV = -1 # must be described, because the variable has not yet been described
+ # several are left over
+ # selection via ranking order of the object types
+ else:
+ for objectTyp in orderRankObjectTypes:
+ # initialization of a list in which all elements of a type are written
+ objectTypeRankList = []
+ for elementCoordList in noGeoDistButAllowedTypeList:
+ if miniGOV[elementCoordList[0]]["Objekttyp als Text"] == objectTyp:
+ objectTypeRankList.append(elementCoordList[0])
+ # one object remains, then select it
+ if len(objectTypeRankList) == 1:
+ positionMiniGOV = objectTypeRankList[0]
+ selectInfo = "Selected on the basis of a suitable type " + supplementSelectInfo
+ return ([positionMiniGOV, selectInfo]) # e. g. a city was found and preferred over a village
+ # multiple hits, none can be selected
+ elif len(objectTypeRankList) > 1:
+ positionMiniGOV = -1
+ selectInfo = "Not selected based on too many matching types " + supplementSelectInfo
+ return ([positionMiniGOV, selectInfo])
+ # if no hit, the loop is repeated with the next object type
+ # this part of the function is only executed if the identification has failed finally
+ selectInfo = "Not selected, because no heuristic gives a result " + supplementSelectInfo
+ positionMiniGOV = -1
+ return ([positionMiniGOV, selectInfo])
+
+
+def stringFunc1(behindTag, string):
+ """
+ This function removes strings from "behindTag".
+ :param behindTag: urbanonym
+ :param string: forbidden string
+ :return: urbanonym purged from the forbidden string
+ """
+ # if it is at the beginning, then take everything behind it, otherwise just delete
+ if string in behindTag: # is not at the beginning
+ if behindTag.find(string) != 0:
+ position = behindTag.find(string)
+ behindTag = behindTag[:position]
+ else: # is at the beginning
+ behindTag = behindTag.replace(string, "")
+ return (behindTag)
+
+
+def stringFunc2(behindTag, string):
+ """
+ This function is used to remove strings in "behindTag" if they are at the beginning.
+ :param behindTag: urbanonym
+ :param string: forbidden string
+ :return: urbanonym purged from the forbidden string
+ """
+ if string in behindTag:
+ if behindTag.find(string) == 0:
+ behindTag = behindTag.replace(string, " ")
+ return (behindTag)
+
+
+def dataCleaner(dataForCleansing):
+ """
+ This function is used to clean up an urbanoynm.
+ :param dataForCleansing: urbanonym (string)
+ :return: adjusted urbanonym (string)
+ """
+ # clean an urbanonym
+ behindTag = dataForCleansing # data behind GEDCOM tag "PLAC" (the urbanoynm)
+ behindTag = behindTag.lower() # behindTag lower cases for better cleansing
+ # cleansing of behindTag
+ # attention: order of cleansing operations is relevant
+ # definition of banned words
+ letters = ["a",
+ "b",
+ "c",
+ "d",
+ "e",
+ "f",
+ "g",
+ "h",
+ "i",
+ "j",
+ "k",
+ "l",
+ "m",
+ "n",
+ "o",
+ "p",
+ "w",
+ "r",
+ "s",
+ "t",
+ "u",
+ "v",
+ "w",
+ "x",
+ "y",
+ "z"
+ ]
+ # exclude the possibility that an abbreviation of a US state appears at the end
+ if behindTag[-4:-2] == ", " and behindTag[-2:-1] in letters and behindTag[-1:] in letters:
+ behindTag = "unrealisticSequenceOfStringsAlpha"
+ # definition of words that must not be included in the urbanonym
+ # banning abbreviations of staats is critial because thats are beginnigs of other places
+ for bannedWords in ["kanada",
+ "canada",
+ "america",
+ "united states",
+ " usa",
+ "alabama",
+ "alaska",
+ "arizona",
+ "arkansas",
+ "california",
+ "colorado",
+ "connecticut",
+ "delaware",
+ "florida",
+ "georgia",
+ "hawaii",
+ "idaho",
+ "illinois",
+ "indiana",
+ "iowa",
+ "kansas",
+ "kentucky",
+ "louisiana",
+ "maine",
+ "maryland",
+ "massachusetts",
+ "michigan",
+ "minnesota",
+ "mississippi",
+ "missouri",
+ "montana",
+ "nebraska",
+ "nevada",
+ "new hapshire",
+ "new jersey",
+ "new york",
+ "north carolina",
+ "north dakota",
+ "ohio",
+ "oklahoma",
+ "oregon",
+ "pennsylvania",
+ "rohde island",
+ "south carolina",
+ "south dakota",
+ "tennessee",
+ "texas",
+ "utah",
+ "vermont",
+ "virginia",
+ "washington",
+ "west virginia",
+ "wisconsin",
+ "wyoming",
+ "england",
+ "united kingdom",
+ "australia",
+ "spain",
+ "espagne",
+ "glamorga",
+ "russia",
+ "luxembourg",
+ "scotland",
+ "irland",
+ "norway",
+ "griechenland",
+ "turkey",
+ "südafrika",
+ "brasil",
+ "france"]:
+ if bannedWords in behindTag:
+ behindTag = "unrealisticSequenceOfStringsAlpha"
+ # definition of words that must not be equal to the urbanonym
+ for bannedWords in ["germany",
+ "poland",
+ "france",
+ "russland"]: # ausschließlich das, nicht "enthält"
+ if bannedWords == behindTag:
+ behindTag = "unrealisticSequenceOfStringsBeta"
+
+ # if there is no space behind a dot, it should be added
+ if "." in behindTag:
+ position = behindTag.find(".")
+ if behindTag[position:position + 1] != " ":
+ behindTag = behindTag[:position] + " " + behindTag[position:]
+ # removal of defined strings
+ behindTag = behindTag.replace(">", "") # remove ">"
+ behindTag = behindTag.replace("<", "") # remove "<"
+ behindTag = behindTag.replace("_", "") # remove "_"
+ behindTag = behindTag.replace("'", "") # remove "'"
+ behindTag = behindTag.replace("rk.", "") # remove "rk."
+ behindTag = behindTag.replace("ev.", "") # remove "ev."
+ behindTag = behindTag.replace("waldfriedhof", "") # remove "("waldfriedhof"
+ behindTag = behindTag.replace("friedhof", "") # remove "friedhof"
+ behindTag = behindTag.replace("wahrscheinlich", "") # remove "wahrscheinlich"
+ behindTag = behindTag.replace("aus ", "") # remove "aus "
+ # remove numbers
+ behindTag = behindTag.replace("0", "")
+ behindTag = behindTag.replace("1", "")
+ behindTag = behindTag.replace("2", "")
+ behindTag = behindTag.replace("3", "")
+ behindTag = behindTag.replace("4", "")
+ behindTag = behindTag.replace("5", "")
+ behindTag = behindTag.replace("6", "")
+ behindTag = behindTag.replace("7", "")
+ behindTag = behindTag.replace("8", "")
+ behindTag = behindTag.replace("9", "")
+ # remove 7-bit ASCII
+ behindTag = behindTag.replace("\xa7", "ß")
+ behindTag = behindTag.replace("\x94", "ö")
+ behindTag = behindTag.replace("\x9a", "ö")
+ behindTag = behindTag.replace("\x8a", "ä")
+ behindTag = behindTag.replace("\x9f", "ü")
+ # removal of further special characters
+ behindTag = behindTag.replace("(?)", "") # before removing "?", otherwise many problems with empty brackets
+ behindTag = behindTag.replace("?", "") # often standing alone or behind places
+ behindTag = behindTag.replace(" -", "") # only with spaces in front, not as hyphen
+
+ # definition of strings to be removed
+ stringFunc1List = ["standesamt ",
+ "sta ",
+ "ksp. ",
+ "ksp ",
+ "kirchspiel ",
+ "kirche ",
+ "pfarramt ",
+ "ambt ",
+ "oder ",
+ "gemeinde ",
+ "gmde. ",
+ "gmde ",
+ "pfarrei ",
+ "gericht ",
+ "ksp. "
+ ]
+ for i in stringFunc1List:
+ behindTag = stringFunc1(behindTag, i)
+
+ # definition of strings to be deleted if they are at the beginning
+ stringFunc2List = [" bei ",
+ " b. ",
+ " in ",
+ " im "
+ ]
+ for i in stringFunc2List:
+ behindTag = stringFunc2(behindTag, i)
+
+ # writing out abbreviations
+ behindTag = behindTag.replace("berg. ", "bergisch ") # Example: Bergisch Gladbach
+ behindTag = behindTag.replace("b. ", "bei ") # Lichtenau b. Ansbach
+
+ # deletion of not needed content
+ if "jetzt" in behindTag: # Example: Grone jetzt Göttingen
+ position = behindTag.find(" jetzt")
+ behindTag = behindTag[:position]
+ if "heute" in behindTag: # Example:
+ position = behindTag.find(" heute")
+ behindTag = behindTag[:position]
+ if " um" in behindTag: # Example: ... um 12 Uhr
+ position = behindTag.find(" um")
+ behindTag = behindTag[:position]
+ if " bei" in behindTag: # Example: Lipke bei Landsberg
+ position = behindTag.find(" bei")
+ behindTag = behindTag[:position]
+ if " kr." in behindTag: # Example: Bronn Kr. Mergentheim
+ position = behindTag.find(" kr.")
+ behindTag = behindTag[:position]
+ if " amt" in behindTag:
+ position = behindTag.find(" amt")
+ behindTag = behindTag[:position]
+ if "/" in behindTag: # Example: Crossen/Oder
+ position = behindTag.find("/")
+ behindTag = behindTag[:position]
+ while behindTag[:1] == ",": # delete preceding commas
+ behindTag = behindTag[1:]
+ if "," in behindTag: # Example: Arendzhain, Kreis Luckau
+ position = behindTag.find(",")
+ behindTag = behindTag[:position]
+ if " in " in behindTag: # Example: Taufe in Ogkeln
+ position = behindTag.find(" in ")
+ behindTag = behindTag[(position + len(" in ")):]
+
+ # eliminate double spaces
+ behindTag = behindTag.replace(" ", " ")
+ # eliminate spaces
+ behindTag = behindTag.strip(" ")
+
+ # overwrite return value
+ dataForCleansing = behindTag
+ return (dataForCleansing)
+
+
+def bannedObjects():
+ """
+ This function defines banned object types.
+ Banned object types are object types in the GOV that should not be used for identification.
+ Currently all ecclesiastical objects (up to and including 263) are banned.
+ Currently all legal objects (e.g. courts, from 263) are banned.
+ Currently administrative divisions outside Germany that make allocation difficult (from 257) are banned.
+ List of object types: http://gov.genealogy.net/type/list (retrieved on 8 December 2020)
+ Sometimes there is no English translation of the names of the object types.
+ :return: list of banned object types
+ """
+ return (["124", # imperial abbey
+ "250", # Apostolische Administratur
+ "6", # diocese
+ "91", # Bistumsregion
+ "9", # deanery
+ "260", # Delegaturbezirk
+ "11", # diocese
+ "12", # Dompfarrei
+ "13", # filial church
+ "249", # Erzbischöfliches Amt
+ "96", # archbishopric
+ "219", # Expositur
+ "245", # chapel
+ "26", # church
+ "210", # Kirchenbund
+ "92", # Kirchengemeinde
+ "27", # Kirchenkreis
+ "28", # Kirchenprovinz
+ "29", # parish
+ "153", # Kommissariat
+ "35", # national church
+ "243", # Propstei
+ "244", # Nebenkirche
+ "245", # chapel
+ "249", # Erzbischöfliches Amt
+ "41", # Pfarr-Rektorat
+ "42", # parish
+ "155", # region
+ "43", # Pfarrkuratie
+ "44", # Pfarrverband
+ "155", # region
+ "206", # selsoviet
+ "253", # religious organization
+ "49", # sprengel
+ "260", # Delegaturbezirk
+ "263", # Landratsbezirk
+ "151", # Oberlandesgericht
+ "105", # judicial
+ "3", # Magistrates' Court
+ "223", # Landgericht
+ "224", # Pfleggericht
+ "228", # Gerichtsamt
+ "19", # Gerichtsbezirk
+ "70", # bailiwick
+ "79", # hundred
+ "114", # Vest
+ "154", # Honschaft
+ "202", # Amtsgerichtsbezirk
+ "257", # Landgemeinde PL
+ "264", # Mairie
+ "135", # canton
+ "134", # arrondissement
+ "25" # canton
+ ])
+
+
+def mainPlaceFinder(data, resultQualityChecker, filename, miniGov):
+ """
+ This function attempts to assign a GOV identifier to each location in a GEDCOM file.
+ :param data: content of one GEDCOM file
+ :param resultQualityChecker: content for one line of the file "quality.csv"
+ :param filename: name of the file/source
+ :param miniGov: list of merged entries of the Mini-GOV
+ :return: list of dictionaries, which contains the identification for each location
+ """
+ # copy the content to avoid compression
+ gedcomMetaInfo = resultQualityChecker
+
+ # definition of banned object types
+ # banned object types are object types in the GOV that should not be used for identification
+ # currently all ecclesiastical objects (up to and including 263), all legal objects (e.g. courts, from 263) and administrative divisions outside Germany that make allocation difficult (from 257)
+ # list of object types: http://gov.genealogy.net/type/list (retrieved on 8 December 2020)
+ # sometimes there is no English translation of the names of the object types
+ bannedObjectTypes = bannedObjects()
+
+ # "data" is compromised by the dataCleaner function and could no longer be used
+ # therefore a copy must be created that does not represent a pointer (that's why copy.copy is used)
+ initialGedcomData = copy.copy(data)
+ gedcomData = copy.copy(data)
+
+ # clean up every urbanonym in a GEDCOM file
+ # clean each row in gedcomData
+ for cleanCounter in range(len(gedcomData)):
+ resultParser = qualitychecker.gedcomRowParser(gedcomData, cleanCounter) # seperate data of one row
+ tag = resultParser[2] # GEDCOM tag
+ behindTag = resultParser[3] # data behind GEDCOM tag
+ behindTag = behindTag.lower() # behindTag lower cases for better cleansing
+ # for urbanonyms:
+ if tag == "PLAC":
+ dataCleaned = dataCleaner(behindTag)
+ # overwrite the original GEDCOM line with the cleaned text
+ gedcomData[cleanCounter] = resultParser[0] + " " + resultParser[2] + " " + dataCleaned
+
+ # creation of a list of locations and their sources
+ locList = []
+ for counter, i in enumerate(gedcomData):
+ if i[2:6] == "PLAC":
+ # adjusted urbanonym, original urbanonym, name of file
+ locList.append([i[7:], initialGedcomData[counter][7:], filename])
+
+ # delete duplicates in a source
+ locList = sorted(set(map(tuple, locList)), reverse=True)
+
+ # creation of a list containing the identifying data per urbanonym in a dictionary
+ resultList = []
+ for counter, i in enumerate(locList):
+ locNameClean = i[0] # ubanonym with cleansing
+ locName = i[1] # urbanoym without cleansing
+ fileName = i[2]
+ # find place
+ resultPlaceFinder = placeFinder(locNameClean,
+ miniGov,
+ gedcomMetaInfo,
+ bannedObjectTypes
+ )
+ # create dictionary
+ identifyingInfo = {
+ "id": resultPlaceFinder[0],
+ "latitude": resultPlaceFinder[1],
+ "longitude": resultPlaceFinder[2],
+ "selection information": resultPlaceFinder[3],
+ "adjusted name": locNameClean,
+ "original name": locName,
+ "filename": fileName
+ }
+ resultList.append(identifyingInfo)
+ return (resultList)
diff --git a/2022_005_goldberg_v1_1/Skripte/provincefinder.py b/2022_005_goldberg_v1_1/Skripte/provincefinder.py
new file mode 100644
index 0000000000000000000000000000000000000000..f1b8eb8d1c6320f74fe361f5d2b013d3356d32dc
--- /dev/null
+++ b/2022_005_goldberg_v1_1/Skripte/provincefinder.py
@@ -0,0 +1,404 @@
+import julian
+import placefinder
+import time
+
+
+def provincesURI(time):
+ """
+ This function defines the URIs of different regions at different times.
+ :param time: year to which an administrative assignment should be made
+ :return: dictionary of GOV object URIs and the textual description of the respective province
+ """
+ # for times before 1872
+ if time <= 1871:
+ return ({
+ "object_190122": "A 01 Provinz Holstein",
+ # Problem in the GOV: The places are not linked to the historical offices, so the province is never found
+ "adm_131053": "A 02 Provinz Lauenburg",
+ "object_1081716": "A 03 Provinz Brandenburg (ohne Berlin)",
+ # if Berlin is meant, it will be recorded before
+ "object_190330": "A 04 Provinz Hessen-Nassau",
+ "object_268785": "A 05 Provinz Hohenzollern",
+ "object_284443": "A 05 Provinz Hohenzollern",
+ # Hohenzollern-Sigmaringen goes 1850 to Hohenzollerschen Landen
+ "adm_368500": "A 06 Provinz Ostpreußen",
+ "adm_368480": "A 07 Provinz Pommern",
+ "object_211667": "A 08 Provinz Posen",
+ "object_279654": "A 09 Provinz Sachsen",
+ "adm_368470": "A 10 Provinz Schlesien",
+ "object_190325": "A 11 Provinz Westfalen",
+ "object_213750": "A 12 Provinz Westpreußen",
+ "object_1047283": "A 13 Rheinprovinz", # Provinz Jülich-Kleve-Berg until 1822
+ "object_405464": "A 13 Rheinprovinz", # Provinz Großherzogtum Niederrhein until 1822
+ "object_190337": "A 13 Rheinprovinz",
+ "BERLINJO62PM": "A 14 Provinz Berlin",
+ "object_257607": "B 01 Amt Bergedorf",
+ "adm_369040": "B 02 Hansestadt Bremen",
+ "adm_369020": "B 03 Stadt Hamburg",
+ "LUBECKJO53IU": "B 04 Stadt Lübeck",
+ "adm_136412": "B 05 Stadt Frankfurt am Main",
+ "object_217406": "B 06 Fürstentum Lippe-Detmold",
+ "object_217818": "B 07 Fürstentum Schaumburg-Lippe",
+ "object_218152": "B 08 Fürstentum Waldeck-Pyrmont",
+ "object_352387": "B 09 Großherzogtum Oldenburg",
+ "object_217952": "B 10 Großherzogtum Baden",
+ "object_218147": "B 11 Hessen",
+ "object_217750": "B 12 Großherzogtum Mecklenburg-Schwerin",
+ "object_217749": "B 13 Großherzogtum Mecklenburg-Strelitz (einschließlich des Fürstentums Ratzeburg)",
+ "object_190873": "B 14 Herzogtum Anhalt",
+ "object_217954": "B 15 Herzogtum Braunschweig",
+ "object_218153": "B 16 Herzogtum Nassau",
+ "object_190098": "B 17 Herzogtum Schleswig",
+ "object_190729": "B 18 Königreich Württemberg",
+ "object_217953": "B 19 Königreich Bayern",
+ "object_190327": "B 20 Königreich Hannover",
+ "object_218149": "B 21 Königreich Sachsen",
+ "object_275299": "B 22 Kurfürstentum Hessen", # here equated with Kurhessen
+ "object_284442": "B 23 Landgrafschaft Hessen-Homburg",
+ "": "B 24 Thüringische Staaten", # is divided into many sub-states as follows
+ "object_218143": "B 24 Thüringische Staaten", # Sachsen-Weimar-Eisenach
+ "object_284441": "B 24 Thüringische Staaten", # Reuß Jüngere Linie
+ "object_218134": "B 24 Thüringische Staaten", # Reuß Ältere Linie
+ "object_218137": "B 24 Thüringische Staaten", # Sachsen-Altenburg
+ "object_218138": "B 24 Thüringische Staaten", # Sachsen-Coburg-Gotha
+ "object_265487": "B 24 Thüringische Staaten", # Sachsen Gotha
+ "object_218142": "B 24 Thüringische Staaten", # Sachsen-Meiningen
+ "object_218150": "B 24 Thüringische Staaten", # Schwarzburg-Rudolstadt
+ "object_218151": "B 24 Thüringische Staaten", # Schwarzburg-Sondershausen
+ "object_218141": "B 24 Thüringische Staaten" # Sachsen-Hildburghausen, has no subordinate objects
+ })
+ # for times after 1989
+ elif time >= 1990:
+ return ({
+ "BERLINJO62PM": "Land Berlin",
+ "object_218149": "Freistaat Sachsen",
+ "adm_369080": "Land Baden-Württemberg",
+ "adm_369090": "Freistaat Bayern",
+ "adm_369120": "Land Brandenburg",
+ "adm_369040": "Freie Hansestadt Bremen",
+ "object_1259992": "Freie und Hansestadt Hamburg",
+ "adm_369060": "Land Hessen",
+ "adm_369130": "Land Mecklenburg-Vorpommern",
+ "adm_369030": "Land Niedersachsen",
+ "adm_369050": "Land Nordrhein-Westfalen",
+ "adm_369070": "Land Rheinland-Pfalz",
+ "adm_369100": "Saarland",
+ "adm_369150": "Land Sachsen-Anhalt",
+ "adm_369010": "Land Schleswig-Holstein",
+ "adm_369160": "Freistaat Thüringen"
+ })
+
+
+def provinceFinder(govid, referenceYear, client):
+ """
+ This function determines the historical-administrative affiliation to an object at a given time.
+ :param govid: GOV identifier (string)
+ :param referenceYear: year to which an administrative assignment should be made
+ :param client: connection to the GOV-Webservice
+ :return: province or "None"
+ """
+ # if this variable is 1, the program will be stopped for one second in case of internet connection failures
+ # this prevents an abort of the program due to internet problems, but leads to a longer runtime
+ withSleeping = 0
+
+ # definition of prohibited object types
+ bannedObjectTypes = placefinder.bannedObjects()
+ # assignment of objects to be found and historical-administrative units
+ provinces = provincesURI(referenceYear)
+
+ # if GOV identifier empty, then return None
+ if govid == "":
+ return ("None")
+
+ govidBefore = 0 # Initialisierung
+ # following loop jumps one level up in the membership tree per iteration
+ # number of 10 is currently chosen arbitrarily, in the hope that no tree has more levels
+ for ab in range(0, 10):
+ # here, possible superordinate objects are included, which are appropriate in time
+ govidsList = [] # list A, priority
+ # List B (non priority) is required if no object fits so well that it is included in List A.
+ nonPrioGovidsList = [] # list B, non priority
+ # termination condition: if the same object is examined twice in a row, then abort
+ # query is used to improve the runtime, so that the same object is not searched max. 10 times
+ if govid == govidBefore:
+ print("Error: Object can no longer take a meaningful step (GOV-ID, GOV-ID before):", govid, govidBefore)
+ break
+ # since "govid" changes, the previous one must be cached
+ govidBefore = govid
+ # check if the object already matches a province
+ try: # if yes, then there is no KeyError
+ province = provinces[govid]
+ return (province)
+ except KeyError:
+ # information about the object is obtained from the web service (a dictionary that is composed of dictionary)
+ if withSleeping == 1:
+ for run in range(1000):
+ try:
+ govidInfo = callWebservice(govid, client)
+ except: # if the connection is just gone the program should not crash
+ time.sleep(1)
+ print("Status: Sleeping for 1 s.")
+ if run == 999:
+ print("Status: Connection error")
+ else:
+ govidInfo = callWebservice(govid, client)
+ # from this the entry "part-of" is required
+ govidInfoSuperior = govidInfo['part-of']
+ # if "part-of" is empty, then the info is in "located-in" if necessary
+ if len(govidInfoSuperior) == 0:
+ govidInfoSuperior = govidInfo["located-in"]
+
+ # every superior object is now searched
+ # The date can be in three places: 1. in timespan (), in begin-year, end-year, 3. in year
+ for superior in range(len(govidInfoSuperior)):
+ # if timespan available
+ # if timespan is not None, use the years from it
+ if govidInfoSuperior[superior]["timespan"] is not None:
+ yearBegin = begincalculator(govidInfoSuperior[superior])
+ yearEnd = endcalculator(govidInfoSuperior[superior])
+ # check if the timespan matches the searched time
+ # if yes a list is extended
+ if yearBegin <= referenceYear and yearEnd >= referenceYear:
+ govid = govidInfoSuperior[superior]["ref"]
+ if callWebservice(govid, client)["type"][0]["value"] not in bannedObjectTypes:
+ govidsList.append(govid)
+ else:
+ if callWebservice(govidInfoSuperior[superior]["ref"], client)["type"][0][
+ "value"] not in bannedObjectTypes:
+ nonPrioGovidsList.append(govidInfoSuperior[superior]["ref"])
+ # if timespan not available
+ else:
+ try:
+ # begin is determined
+ if govidInfoSuperior[superior]["begin-year"] is None:
+ yearBegin = 1 # sets begin to year 1
+ else:
+ yearBegin = govidInfoSuperior[superior]["begin-year"]
+ # end is determined
+ if govidInfoSuperior[superior]["end-year"] is None:
+ yearEnd = 9999 # set end to year 9999
+ else:
+ yearEnd = govidInfoSuperior[superior]["end-year"]
+ # if an object has an assumed time (start 1, end 9999), then always list B (problem otherwise e.g. with KIRORFJO40NS, adm_137138)
+ if yearBegin == 1 or yearEnd == 9999:
+ if callWebservice(govidInfoSuperior[superior]["ref"], client)["type"][0][
+ "value"] not in bannedObjectTypes:
+ nonPrioGovidsList.append(govidInfoSuperior[superior]["ref"])
+ # comparison with reference time
+ elif yearBegin <= referenceYear and yearEnd >= referenceYear:
+ govid = govidInfoSuperior[superior]["ref"]
+ if callWebservice(govid, client)["type"][0]["value"] not in bannedObjectTypes:
+ govidsList.append(govid)
+ else:
+ if callWebservice(govidInfoSuperior[superior]["ref"], client)["type"][0][
+ "value"] not in bannedObjectTypes:
+ nonPrioGovidsList.append(govidInfoSuperior[superior]["ref"])
+ except TypeError:
+ print(
+ "Error: A problem has occurred in the calculation of time spans. Presumably there are letters as numbers:",
+ print(govidInfoSuperior[superior]))
+ pass;
+ # if one of the objects in list A or B is one of the target objects, then take the
+ for i in govidsList: # list A
+ try:
+ province = provinces[i]
+ return (province) # Search was successful!
+ except KeyError:
+ continue
+ for i in nonPrioGovidsList: # list B
+ try:
+ province = provinces[i]
+ return (province) # Search was successful!
+ except KeyError:
+ continue
+ # if list A is empty, then list B should be used
+ if len(govidsList) == 0:
+ # if list B is also empty, then you should try to fill it further
+ if len(nonPrioGovidsList) == 0: # Example: Case LIEHA2JO62RV, which has no part-of
+ for a in range(len(govidInfoSuperior)):
+ # the type of the following object is of interest (not the previous one)
+ if callWebservice(govidInfoSuperior[a]["ref"], client)["type"][0][
+ "value"] not in bannedObjectTypes:
+ nonPrioGovidsList.append(govidInfoSuperior[a]["ref"])
+ govidsList = nonPrioGovidsList
+
+ # rate objects in list A or B
+
+ # delete duplicate values
+ # duplicate affiliations to the same object at different times may exist (e.g. adm_144024), but this is recognized below
+ govidsList = list(set(govidsList))
+
+ # if list contains only one object, then this is the appropriate one to perform the next iteration
+ if len(govidsList) == 1:
+ govid = govidsList[0]
+ # if list contains no object, then cancel
+ elif len(govidsList) == 0:
+ # mandatory abort, because no object could be determined to perform the next iteration
+ break;
+ else: # case where list contains more than one value
+ closerInTime = [] # initialization
+ # each object in the list is checked to see how close the time limits are to the reference time
+ for elementGovidsList in govidsList:
+ # a simple list comprehension to find the index is inappropriate, since the searched value can occur several times
+ # therefore a list is created
+ indexList = [] # results are stored in this list
+ for counter, resultPartOf in enumerate(govidInfoSuperior):
+ if resultPartOf["ref"] == elementGovidsList:
+ indexList.append(counter)
+ if len(indexList) == 0:
+ index = None
+ print("Error: The object name does not occur.")
+ for index in indexList:
+ if govidInfoSuperior[index][
+ "timespan"] is not None: # if timespan is given, then it is more detailed
+ yearBegin = begincalculator(govidInfoSuperior[index])
+ yearEnd = endcalculator(govidInfoSuperior[index])
+ # if only one year, but no begin or end
+ elif govidInfoSuperior[index]["begin-year"] is None and \
+ govidInfoSuperior[index]["end-year"] is None and \
+ govidInfoSuperior[index]["year"] is not None:
+ yearBegin = govidInfoSuperior[index]["year"]
+ yearEnd = govidInfoSuperior[index]["year"]
+ else: # if no timespan
+ yearBegin = govidInfoSuperior[index]["begin-year"]
+ if yearBegin is None: # if there is no value
+ yearBegin = 1
+ yearEnd = govidInfoSuperior[index]["end-year"]
+ if yearEnd is None:
+ yearEnd = 9999
+ diffBegin = abs(yearBegin - referenceYear)
+ diffEnd = abs(yearEnd - referenceYear)
+ clusterDict = {
+ "object": elementGovidsList,
+ "diffbegin": diffBegin,
+ "diffend": diffEnd,
+ "begin-year": yearBegin,
+ "end-year": yearEnd
+ }
+ closerInTime.append(clusterDict) # list of dictionaries
+ diff = 9999 # initialization
+ # In the following it is examined which of the chronologically obvious results is the closest in time.
+ # it is irrelevant whether the difference lies before or after the reference time
+ for counter, i in enumerate(closerInTime):
+ # Equal comparisons are critical in cases where time limits overlap (e.g. object_289942 --> until 1920, since 1920)
+ if int(i["diffbegin"]) < diff:
+ diff = int(i["diffbegin"])
+ closestInTime = counter
+ elif int(i["diffbegin"]) == diff:
+ # search the absolute value of the start (not the difference)
+ yearBegin = i["begin-year"]
+ # if reference period is smaller than diffbegin
+ if referenceYear <= yearBegin:
+ # if it is "begin" and the other "end", then take the one with the end
+ # if the previous is no end (then neither + nor - 0), then take after new
+ if (closerInTime[closestInTime]["diffend"] + diff) != 0 and (
+ closerInTime[closestInTime]["diffend"] - diff) != 0:
+ closestInTime = counter
+ # larger
+ elif referenceYear > yearBegin:
+ # if the previous one is no beginning (then neither + nor - 0), then move to new one
+ if (closerInTime[closestInTime]["diffbegin"] + diff) != 0 and (
+ closerInTime[closestInTime]["diffbegin"] - diff) != 0:
+ closestInTime = counter
+ if int(i["diffend"]) < diff:
+ diff = int(i["diffend"])
+ closestInTime = counter
+ elif int(i["diffend"]) == diff:
+ # search the beginning of the year
+ yearEnd = i["end-year"]
+ # if reference period smaller than diffbegin
+ if referenceYear <= yearEnd:
+ # take this if the previous (closestInTime) is a start or no end
+ if (closerInTime[closestInTime]["diffend"] + diff) != 0 and (
+ closerInTime[closestInTime]["diffend"] - diff) != 0:
+ closestInTime = counter
+ # larger
+ elif referenceYear > yearEnd:
+ # take this if the previous one is not a beginning
+ if (closerInTime[closestInTime]["diffbegin"] + diff) != 0 and (
+ closerInTime[closestInTime]["diffbegin"] - diff) != 0:
+ closestInTime = counter
+ # object with the closest reference time is selected
+ # if the reference time is the same, the last object is selected (<=)
+ # Reason: In several regularly occurring special cases (e.g. some places in Poznan) the right one is rather behind
+ govid = closerInTime[closestInTime]["object"]
+ return ("None")
+
+
+def callWebservice(govid, client):
+ """
+ This function calls the GOV webservice.
+ Eine Internetverbindung ist notwendig.
+ :param govid: GOV identifier
+ :param client: connection to the GOV-Webservice
+ :return: information of the GOV about the corresponding GOV identifier
+ """
+ gotObject = client.service.getObject(govid)
+ return (gotObject)
+
+
+def begincalculator(data):
+ """
+ This function converts the timespan data of an object (available as Julian date) into a year number, which describes the beginning of the affiliation.
+ :param data: time information about administrative affiliations
+ :return: year as integer
+ """
+ timespan = data["timespan"]
+ if timespan["begin"] is not None:
+ begin = timespan["begin"]
+ jd = begin["jd"] - 2400000 # julian date
+ yearBegin = julian.from_jd(jd, fmt='mjd')
+ yearBegin = int(yearBegin.year) # must be int to compare it
+ else:
+ yearBegin = 1 # then set the start to a very early year
+ return (yearBegin)
+
+
+def endcalculator(data):
+ """
+ This function converts the timespan data of an object (available as Julian date) into a year number, which describes the end of membership.
+ :param data: time information about administrative affiliations
+ :return: year as integer
+ """
+ timespan = data["timespan"]
+ if timespan["end"] is not None:
+ end = timespan["end"]
+ jd = end["jd"] - 2400000 # julian date
+ yearEnd = julian.from_jd(jd, fmt='mjd')
+ yearEnd = int(yearEnd.year) # must be int to compare it
+ else:
+ yearEnd = 9999 # then set the end to a very late year
+ return (yearEnd)
+
+
+def mainProvinceFinder(resultPlaceFinder, filename, client, time):
+ """
+ This function assigns the identified urban names to a historical province.
+ :param resultPlaceFinder: list of dictionaries, which contains the identification for each location
+ :param filename: name of the file/source
+ :param client: connection to the GOV-Webservice
+ :param time: year to which an administrative assignment should be made
+ :return: list of dictionaries containing urbanonym, source, GOV-identifier and assigned provinces
+ """
+
+ # perform clustering for each urbanonym of the identification
+ provincesDictList = []
+ for counter, i in enumerate(resultPlaceFinder):
+ # only edit entries that match the source
+ if i["filename"] != filename:
+ continue; # only happens with data loaded from CSV
+ govid = i["id"] # GOV identifier
+ # if identification has failed, then clustering cannot be successful
+ if govid != "NONE":
+ # trigger clustering if identification is successful
+ resultProvinceFinder = provinceFinder(govid, time, client)
+ else:
+ resultProvinceFinder = "NONE"
+ provincesDict = {
+ "original name": i["original name"],
+ "filename": i["filename"],
+ "id": govid,
+ "province": resultProvinceFinder
+ }
+ provincesDictList.append(provincesDict)
+ return (provincesDictList)
diff --git a/2022_005_goldberg_v1_1/Skripte/qualitychecker.py b/2022_005_goldberg_v1_1/Skripte/qualitychecker.py
new file mode 100644
index 0000000000000000000000000000000000000000..69a7725df774bcdc66174374c8474e28d97fc6f2
--- /dev/null
+++ b/2022_005_goldberg_v1_1/Skripte/qualitychecker.py
@@ -0,0 +1,384 @@
+from haversine import haversine
+
+
+def prePlaceFinder(data, minigov, fileName):
+ """
+ This function creates a list of all unique urban names within a source.
+ The function works only with GEDCOM files as source (in this specification).
+ If other files are available as sources, an adjustment is necessary here.
+ :param data: content of one GEDCOM file
+ :param minigov: list of merged entries of the Mini-GOV
+ :return: list of uniquely identifiable locations (based on the name without context)
+ """
+ placelist = []
+ for gedcomRow in data:
+ if "PLAC" in gedcomRow:
+ # overwrite the row by deleting the tag information
+ # +5 because "PLAC" has four characters followed by a space
+ gedcomRow = gedcomRow[gedcomRow.find("PLAC") + 5:]
+ # searching in the Mini-GOV
+ minigovSearchResult = minigovSearch(minigov, gedcomRow)
+ rowInMiniGOV = minigovSearchResult[0]
+ # if there was a unique match, rowInMiniGOV is unequal -1
+ if rowInMiniGOV != -1:
+ govId = minigov[rowInMiniGOV]["GOV-Kennung"] # GOV id of the detected place
+ longitude = minigov[rowInMiniGOV]["geographische Länge"] # longitude
+ latitude = minigov[rowInMiniGOV]["geographische Breite"] # latitude
+ else: # with no clear hit
+ govId = "NONE"
+ longitude = "NONE"
+ latitude = "NONE"
+ # extend a list of places each with a dictionary
+ placeDict = {
+ "place": gedcomRow,
+ "govid": govId,
+ "longitude": longitude,
+ "latitude": latitude,
+ "filename": fileName,
+ "numberHits": minigovSearchResult[1] # can be "1", ">1" or "<1"
+ }
+ placelist.append(placeDict)
+ return (placelist)
+
+
+def gedcomRowParser(data, counter):
+ """
+ The function parses GEDCOM rows into their individual components.
+ :param data: content of a GEDCOM file
+ :param counter: number of GEDCOM row
+ :return: list of four elements (first character, content behind first char, tag, content behind tag)
+ """
+ # save first character
+ firstChar = data[counter][:1]
+
+ # content after the first character excluding the first space
+ behindFirstChar = data[counter][2:]
+
+ # parsing of the tag
+ # if there is no further text behind the tag, then there is no space
+ try:
+ tag = behindFirstChar[:(behindFirstChar.index(" "))]
+ except ValueError:
+ tag = behindFirstChar
+
+ # content behind the tag
+ try:
+ behindTag = behindFirstChar[((behindFirstChar.index(" ")) + 1):]
+ except ValueError:
+ behindTag = ""
+ return ([firstChar, behindFirstChar, tag, behindTag])
+
+
+def minigovSearch(minigov, value):
+ """
+ This function searches the Mini-GOV for location names.
+ :param minigov: list of merged entries of the Mini-GOV
+ :param value: name of the urbanonym
+ :return: List with two values (1. contains the line number in the Mini-GOV if the search result is unique, otherwise -1; 2. contains how many hits were found)
+ """
+ # name of the column of the Mini-GOV to be searched
+ key = "aktueller Name"
+
+ # initial base cleanup of the place name
+ # cut off everything from the first comma
+ try:
+ valueCleaned = value[:value.index(",")]
+ except ValueError:
+ valueCleaned = value
+
+ # initialization of a list in which the line numbers of matching Mini-GOV entries are collected
+ hitsNumberList = []
+ # initialization of a list in which the urbanonyms of matching Mini-GOV entries are collected
+ hitsUrbanonymList = []
+
+ # Binary search algorithm for searching the Mini-GOV
+ # initial position is the center of the Mini-GOV
+ position = int(len(minigov) / 2)
+ # position value of the previous iteration
+ # initially not 0, because this would lead to complex numbers in the formulas (roots of negative numbers)
+ previousPosition = len(minigov)
+ # search until the distance to the previous position is less than 10
+ while (previousPosition - position) not in range(-10, 10):
+ previousPositionCache = position # temporary storage, because position changes and the previous value prevoiusPosition is still needed
+ if valueCleaned > minigov[position][key]: # alphabetical comparison
+ position = position + int(
+ abs(previousPosition - position) / 2) # amount of the difference between previousPosition and pos / 2
+ elif valueCleaned < minigov[position][key]: # alphabetical comparison
+ position = position - int(
+ abs(previousPosition - position) / 2) # amount of the difference between previousPosition and pos / 2
+ elif valueCleaned == minigov[position][key]: # alphabetical comparison, equalness
+ break; # it can not get any more precise than that, so do a break
+ previousPosition = previousPositionCache
+ # if a position was found, the 30 values above and below this position should be compared with valueCleaned
+ # no place name occurs 60 times, therefore the 30 is chosen
+ try:
+ minigov[position - 30][key]
+ start = position - 30
+ except IndexError: # which occurs when the position is quite far ahead
+ start = 0 # then start at the beginning
+ try:
+ minigov[position + 30][key]
+ end = position + 30
+ except IndexError: # which occurs when the number is quite far back
+ end = len(minigov) # then end the search at the end
+ # compare from start to finish if the value from the Mini-GOV matches the name of the source
+ for i in range(start, end):
+ if minigov[i][key] == valueCleaned:
+ hitsNumberList.append(i)
+ hitsUrbanonymList.append(valueCleaned)
+
+ # if only one unique value is found, pass the line number from the Mini-GOV and the information that there was only one hit
+ if len(hitsNumberList) == 1:
+ return ([hitsNumberList[0], "1"])
+ # with more than one hit it should be made clear with -1 that no clear hit was achieved
+ elif len(hitsNumberList) > 1:
+ return ([-1, ">1"])
+ # with less than one hit, -1 should be used to indicate that no clear hit was achieved
+ elif len(hitsNumberList) < 1:
+ return ([-1, "0"])
+
+
+def qualityChecker(content, placelist, previousQualityData, filename):
+ """
+ This function is used to get qualitative parameters for each GEDCOM file.
+ This includes, for example, the information about the number of persons.
+ In this program, the determined data is also called metadata of the source.
+ :param content: contents of the GEDCOM file
+ :param placelist: list of uniquely identifiable locations in the source
+ :param previousQualityData: source metadata from previous processing runs
+ :param filename: name of GEDCOM file
+ :return: list of quality parameters or a string as termination condition if the file has already been processed
+ """
+ # prepare qualitychecker()
+ minOneFileIsMissing = 0 # binary variable for detection of missing files in result-csv; if is is 1, min. one gedcom file is not in the csv
+
+ # check if the file has been edited before
+ # if nothing is found, qualityIndex is None, otherwise the number of the row is contained
+ qualityIndex = next((index for (index, d) in enumerate(previousQualityData) if d["filename"] == filename), None)
+ if qualityIndex is not None:
+ # define a string as termination condition
+ # if the file has already been edited once, it should not be edited a second time
+ quality = "StartingExitStrategy"
+ return (quality)
+ else: # file has not been edited yet
+ # initialising of variables
+ numberOfCoordinates = 0 # counter how many unique coordinates in file
+ numberOfPLAC = 0 # counts the number of PLAC tags
+ latitude = 0
+ longitude = 0
+ numberClusters = 1 # number of created clusters
+ haversineDict = { # for clustering, initial always (0,0) as first value
+ "coordinates": (0, 0), # it is okay, because it is in the sea and all places are far away
+ "cluster": 0,
+ "filename": 0
+ }
+ clusterList = [haversineDict]
+
+ # call each line of the GEDCOM file in sequence
+ for i in range(len(content)):
+ # parse a GEDCOM line
+ resultParser = gedcomRowParser(content, i)
+ tag = resultParser[2]
+ behindTag = resultParser[3]
+
+ # cleanup of the content; removal of the content from the first comma
+ try:
+ behindTag = behindTag[:behindTag.index(",")]
+ except ValueError:
+ behindTag = behindTag
+
+ # if they are urbanonyms, calculate average coordinates
+ if tag[:4] == "PLAC":
+ numberOfPLAC = numberOfPLAC + 1
+ # formation of clusters of unique values
+ # compare with any unique location in placelist
+ # it is no problem to identify the placelist by the place name, because placelist has by definition only unique values (e.g. 2x Berlin does not work)
+ for placePlacelist in placelist:
+ # comparing
+ if behindTag == placePlacelist["place"] and placePlacelist["longitude"] != "NONE" and \
+ placePlacelist["longitude"] != "":
+ # add coordinates and a number variable
+ longitude = longitude + float(placePlacelist["longitude"]) # are still strings
+ latitude = latitude + float(placePlacelist["latitude"])
+ numberOfCoordinates = numberOfCoordinates + 1
+
+ # clustering of placePlacelist
+ clusterListCache = clusterList # otherwise the list in the loop itself extends infinitely
+ # list of possible clusters for a location
+ clusterAffiliation = [] # must be reset, because otherwise clusters are always found
+ # checking whether an existing cluster is less than 50 km away from a location
+ for singleCluster in clusterListCache:
+ if singleCluster[
+ "cluster"] not in clusterAffiliation: # should not have to examine all other elements of the cluster
+ coordPlace = (float(placePlacelist["latitude"]), float(placePlacelist["longitude"]))
+ coordMeanCluster = singleCluster["coordinates"]
+ # calculation of the distance in kilometers between location and possible other locations in clusters
+ distance = haversine(coordPlace, coordMeanCluster)
+ if distance <= 50: # in kilometers, at zero it is a place that already exists
+ # if the location is closer than 50 km to an existing cluster, the cluster is assigned to a list of possible clusters
+ # a location can belong to several clusters and thus connect them
+ clusterAffiliation.append(singleCluster["cluster"])
+
+ # with only one membership it will be added to the cluster
+ if len(clusterAffiliation) == 1:
+ haversineDict = {
+ "coordinates": (float(placePlacelist["latitude"]), float(placePlacelist["longitude"])),
+ "cluster": clusterAffiliation[0],
+ "filename": placePlacelist["filename"]
+ }
+ clusterList.append(haversineDict) # add to existing cluster
+ # more than one cluster is close under 50 km (clusters are merged)
+ elif len(clusterAffiliation) > 1:
+ # select the cluster name to be kept, which is decisive (the lowest)
+ min = clusterAffiliation[0]
+ for singleClusterAffiliation in clusterAffiliation:
+ if singleClusterAffiliation < min:
+ min = singleClusterAffiliation
+ for singleClusterAffiliation in clusterAffiliation:
+ # all other cluster entries that are not min must be renamed to min
+ if singleClusterAffiliation != min:
+ for singleClusterList in clusterList:
+ if singleClusterList["cluster"] == singleClusterAffiliation:
+ singleClusterList["cluster"] = min # value vom dict ändern
+ # dthen create the new entry for the location
+ haversineDict = {
+ "coordinates": (float(placePlacelist["latitude"]), float(placePlacelist["longitude"])),
+ "cluster": min,
+ "filename": placePlacelist["filename"]
+ }
+ clusterList.append(haversineDict)
+ # no affiliation to a cluster
+ # own cluster is created
+ elif len(clusterAffiliation) == 0:
+ haversineDict = {
+ "coordinates": (float(placePlacelist["latitude"]), float(placePlacelist["longitude"])),
+ "cluster": numberClusters,
+ "filename": placePlacelist["filename"]
+ }
+ clusterList.append(haversineDict)
+ numberClusters = numberClusters + 1 # count the total number of clusters
+
+ # if there was a hit once, there can be no second hit, because placelist has only unique values; coordinates that occur twice are included twice in the calculation, because the whole part is executed multiple times
+ break
+
+ # calculate average coordinates of whole source
+ if numberOfCoordinates != 0: # non-negative condition
+ longitude = longitude / numberOfCoordinates
+ latitude = latitude / numberOfCoordinates
+ else:
+ longitude = "NONE"
+ latitude = "NONE"
+
+ # per GEDCOM file
+ # calculate number of different clusters
+ existingCluster = [] # list of assigned clusters
+ clusterMeanList = [] # list of averages of all clusters in a file for further processing
+ numberOfFinalCluster = 0
+ # save only the numberClusters from the clusterlist
+ for singleClusterList in clusterList:
+ existingCluster.append(singleClusterList["cluster"])
+
+ # save only the coordinates from the clusterlist
+ # set a dot per file location
+ clusterLatLon = []
+ for singleClusterList in clusterList:
+ clusterLatLon.append(
+ [singleClusterList["coordinates"][0], singleClusterList["coordinates"][1], 500]) # regulate intensity
+
+ # calculation of the geographical center of the clusters in a file
+ # definition of a minimum size of locations in a cluster
+ minimumClusterSize = 6 # do not consider all clusters smaller or equal 5
+ # per cluster, basic idea: compare every location with every cluster
+ # create numbers, which can be used as names for the clusters
+ for possibleClusterNumber in range(len(clusterList)):
+ # initialization for the calculation of averages
+ lat = 0
+ long = 0
+ numberLatLong = 0
+ # add coordinates of matching clusters together
+ for singleClusterList in clusterList:
+ if singleClusterList["cluster"] == possibleClusterNumber:
+ lat = lat + singleClusterList["coordinates"][0]
+ long = long + singleClusterList["coordinates"][1]
+ numberLatLong = numberLatLong + 1
+ # via numberLatLong you can exclude small clusters; must be at least 1; must be at least 1
+ # only for clusters that really exist, therefore at least 1
+ if numberLatLong >= minimumClusterSize: # must go here, because otherwise the divider will be distorted and also clusters will be applied where there is no cluster entry (e.g. 23)
+ lat = lat / (numberLatLong) # non-negative
+ long = long / (numberLatLong) # non-negative
+ # the list is used for further calculations to determine/cluster locations
+ clusterMeanList.append([lat, long])
+
+ # counting of left clusters (cluster with the minimum size)
+ existingCluster = stringDuplicateCounter(existingCluster)
+ for singleExistingCLuster in existingCluster:
+ if singleExistingCLuster[1] >= minimumClusterSize:
+ numberOfFinalCluster = numberOfFinalCluster + 1
+
+ # counting hits
+ noHit = 0
+ moreThanOneHit = 0
+ oneHit = 0
+ for singlePlacelist in placelist:
+ if singlePlacelist["numberHits"] == "1":
+ oneHit = oneHit + 1 # in contrast to numberOfCoordinates also those without coordinates
+ elif singlePlacelist["numberHits"] == "0":
+ noHit = noHit + 1
+ elif singlePlacelist["numberHits"] == ">1":
+ moreThanOneHit = moreThanOneHit + 1
+
+ # generation of a dictionary for all meta data
+ quality = {
+ "filename": filename,
+ "longitude mean of of definitely coordinates": longitude,
+ "latitude mean of of definitely coordinates": latitude,
+ "number of places": numberOfPLAC,
+ "number of noHit": noHit,
+ "number of moreThanOneHit": moreThanOneHit,
+ "number of definitely coordinates": oneHit,
+ "number of existing clusters": (len(existingCluster) - 1), # minus 1, because cluster is initial 0
+ "number of relevant clusters": numberOfFinalCluster,
+ "cluster midpoints": clusterMeanList
+ }
+ return (quality)
+
+
+def stringDuplicateCounter(list):
+ """
+ This function is used to count equal values (duplicates) in lists.
+ :param list: list to be examined (one column)
+ :return: list of lists containing the name and number of each element in the list
+ """
+ newList = []
+ attribute = []
+ # examine each element of "list"
+ for counter, i in enumerate(list): # i is an element of the list
+ # for each new element this step is performed
+ if i not in attribute:
+ # count the number of these elements in the list
+ doublingCounter = 0
+ for y in list:
+ if i == y:
+ doublingCounter = doublingCounter + 1
+ newList.append([[i], doublingCounter])
+ attribute.append(i)
+ # alphabetical sorting
+ newList.sort()
+ return (newList)
+
+
+def mainMetadataInspector(line, filename, miniGovList, previousQualityData):
+ """
+ This function first initializes the creation of a list of unique location information in a source.
+ Afterwards it is used to achieve a further analysis of metadata or qualitative features.
+ :param line: contents of the GEDCOM file
+ :param filename: name of the file/source
+ :param miniGovList: list of merged entries of the Mini-GOV
+ :param previousQualityData: source metadata from previous processing runs
+ :return: content for one line of the file "quality.csv"
+ """
+ # creation of a list with unique places
+ placelist = prePlaceFinder(line, miniGovList, filename) # placelist is list of unique locations with coordinates
+ # metadata analysis, calculate some parameters
+ quality = qualityChecker(line, placelist, previousQualityData, filename)
+ return (quality)
diff --git a/2022_005_goldberg_v1_1/Skripte/readme.txt b/2022_005_goldberg_v1_1/Skripte/readme.txt
new file mode 100644
index 0000000000000000000000000000000000000000..ca1e245a476fb2c33fe4f4d91b713b74041ae63a
--- /dev/null
+++ b/2022_005_goldberg_v1_1/Skripte/readme.txt
@@ -0,0 +1,27 @@
+readme
+
+Die folgende Anleitung soll eine Benutzung des Python-Skripts und eine Interpretation der Ergebnisse ermöglichen. Der Programmcode ist kompatibel mit der Python-Version 3.6.
+
+Bibliotheken:
+Damit das Programm ausgeführt werden kann sind ggf. noch weitere Bibliotheken lokal zu installieren. In den ersten Zeilen der jeweiligen Dateien sind die benutzten Bibliotheken angegeben.
+
+Eingangsdateien:
+Das Programm verarbeitet Ortsangaben aus GEDCOM-Dateien. Die GEDCOM-Dateien sind mit fortlaufenden Ziffern zu benennen („1.ged“, „2.ged“ etc.). Ziffern dürfen nicht doppelt genutzt werden. Diese Dateien werden in einem Unterordner „data“ platziert. Wenn andere Quellen als GEDCOM-Dateien verwendet werden sollen, ist eine Veränderung des Programms notwendig. Es ist nicht ratsam, nur eine einzige Liste von Ortsangaben zu verwenden, da das Programm darauf basiert, Ortsangaben eines Kontextes in Beziehung zu setzten. Kontext bedeutet hierbei, dass diese Ortsangaben in einer Quelle gemeinsam (also in einem Kontext) benannt werden, was eine geographische Nähe impliziert. Für alle Ortsangaben eines Kontextes sollte also eine eigene Datei erstellt und verarbeitet werden.
+Im Unterordner „data“ sind auch die Dateien des Mini-GOVs zu finden. Hier sind standardmäßig die Mini-GOVs von Deutschland, Polen, Österreich, Schweiz, Tschechien, Dänemark, Frankreich und den Niederlanden eingebunden.
+Daneben versucht das Programm die Dateien „quality.csv“, „placefinder.csv“ und „provincesdict.csv“ zu öffnen, die im selben Ordner wie die Datei „main.py“ liegen. Das sind gleichzeitig die Ausgabedatei des Programms (siehe unten). Sind diese nicht vorhanden, werden diese neu erzeugt. Sind diese vorhanden, werden die vorhandenen Daten genutzt, um die bereits verarbeiteten GEDCOM-Dateien nicht noch einmal auszuführen. Das hilft vor allen in solchen Fällen, in denen das Programm zwischendurch aufgrund einer nicht kontinuierlich vorhandenen Internetverbindung abbricht (siehe nächster Abschnitt).
+Unstetige Internetverbindung: Das Programm greift auf den GOV-Webservice zu, um Informationen zu einzelnen Ortsangaben abzufragen. Hierzu ist eine dauerhafte Internetverbindung notwendig. Da es insbesondere über einen WLAN-Zugang aber Aussetzer geben kann, bei denen das Programm abbrechen kann, ist eine Verzögerung des Programms bei Internetstörungen einprogrammiert. Diese kann manuell an- und abgeschaltet werden. Die Variable withSleeping befindet sich in der Datei „provincefinder.py“ zu Beginn der Funktion „provinceFinder()“. Wenn sie auf 1 gesetzt wird und eine Verbindung zum Webservice nicht hergestellt werden kann, pausiert das Programm für eine Sekunde. Das führt zugleich allerdings dazu, dass das Programm insgesamt eine längere Durchlaufzeit in Anspruch nimmt. Standardmäßig ist diese Funktion nicht aktiviert.
+
+Parallelisierung:
+Die Verarbeitung von GEDCOM-Dateien läuft parallel ab, um die Geschwindigkeit zu erhöhen. Hierzu kann festgelegt werden, wie viele Rechnerkerne genutzt werden. Dazu ist in der Main der Parameter „Pool()“ jeweils zu verändern. Bleibt er leer, so werden alle verfügbare Rechenkerne genutzt. Im Skript ist die Anzahl der Kerne standardmäßig auf die Nutzung aller verfügbaren Kerne eingestellt.
+Provinzenzuordnung: Die Ortsangaben werden verschiedenen Provinzen zugeordnet. Im Standard sind in der Datei „provincefinder.py“ Provinzen vor 1871 und nach 1990 zugeordnet. Für die Zeit dazwischen ist eine provinzielle Zuordnung nicht möglich. Dieses kann aber beliebig angepasst und erweitert werden. Die Bezugszeit kann in der Main in der Funktion „parallel()“ über die Variable referencetime geändert werden. Sie ist standardmäßig auf das Jahr 1800 eingestellt.
+
+Cluster:
+Die Clusterbildung von Orten nimmt bei deren Identifizierung eine bedeutende Rolle ein. Der Mindestabstand sowie die Mindestanzahl von Orten in einem Cluster kann dabei variiert werden. Der Mindestabstand zwischen zwei Clustern kann in der Datei „qualitychecker.py“ in der Funktion „qualityChecker()“ über die IF-Abfrage „if distance <= 50:“ geändert werden. In derselben Funktion existiert die Variable minimumClusterSize, über die die Mindestgröße eines Clusters variiert werden kann. Standardmäßig ist diese auf 6 Orte eingestellt.
+
+Ausgabedateien:
+Das Programm produziert drei Dateien, in der die einzelnen Spalten per Tabstopp voneinander getrennt sind. Die Datei „quality.csv“ gibt Auskunft über die Beschaffenheit und Qualität der Informationen in den GEDCOM-Dateien. Pro GEDCOM-Datei existiert eine Zeile mit Angaben zum Dateinamen, der Anzahl der Ortsangaben in der Datei, dann diese Anzahl der Ortsangabe aufgeteilt in Orte ohne Treffer (noHit), Orte mit mehr als einem Treffer (moreThanOneHit) und Orte mit genau einem Treffer (definitely coordinates), den Mittelpunkt der Längen- sowie der Breitengrade, die Anzahl existierender Cluster, die Anzahl relevanter Cluster, sowie eine Liste der Koordinaten der Mittelpunkte relevanter Cluster.
+Die Datei „provincesdict.csv“ enthält vier Spalten: Die unveränderte Ortsbezeichnung einer Quelle, den Dateinamen, die GOV-ID und die zugeordnete Provinz. Sie hat den Zweck, dass doppelt vorkommende Ortsbezeichnungen in einer Datei nicht doppelt verarbeitet werden müssen.
+Die Datei „placefinder.csv“ enthält zu jeder Ortsangabe Informationen über die ID (GOV-ID), die Koordinaten, eine Information wie die Zuordnung zur GOV-ID stattgefunden hat, die bereinigte Version des Ortsnamens, den originalen Ortsnamen sowie den Namen der Datei, in der der Name vorkommt
+
+
+Jan Michael Goldberg, 30. Juni 2022
\ No newline at end of file
diff --git a/2022_005_goldberg_v1_1/urbanonyme_2020_001.png b/2022_005_goldberg_v1_1/urbanonyme_2020_001.png
new file mode 100644
index 0000000000000000000000000000000000000000..604c92b720708bd4da27e5c8b62156d02096f217
Binary files /dev/null and b/2022_005_goldberg_v1_1/urbanonyme_2020_001.png differ
diff --git a/2022_005_goldberg_v1_1/urbanonyme_2020_002.png b/2022_005_goldberg_v1_1/urbanonyme_2020_002.png
new file mode 100644
index 0000000000000000000000000000000000000000..4fc4d8c340fabfe74ac8c80a3bbe2e053b2fa018
Binary files /dev/null and b/2022_005_goldberg_v1_1/urbanonyme_2020_002.png differ
diff --git a/2022_005_goldberg_v1_1/urbanonyme_2020_003.png b/2022_005_goldberg_v1_1/urbanonyme_2020_003.png
new file mode 100644
index 0000000000000000000000000000000000000000..683462d856266659b2cef1942249626d101a1f64
Binary files /dev/null and b/2022_005_goldberg_v1_1/urbanonyme_2020_003.png differ
diff --git a/2022_005_goldberg_v1_1/urbanonyme_2020_004.png b/2022_005_goldberg_v1_1/urbanonyme_2020_004.png
new file mode 100644
index 0000000000000000000000000000000000000000..0894e25500445f84c46d5ced3ae334bf2a51ecd9
Binary files /dev/null and b/2022_005_goldberg_v1_1/urbanonyme_2020_004.png differ
diff --git a/2022_005_goldberg_v1_1/urbanonyme_2020_005.png b/2022_005_goldberg_v1_1/urbanonyme_2020_005.png
new file mode 100644
index 0000000000000000000000000000000000000000..40db02fd093dc722f48f75e70f29edbf6e65a943
Binary files /dev/null and b/2022_005_goldberg_v1_1/urbanonyme_2020_005.png differ
diff --git a/2022_005_goldberg_v1_1/urbanonyme_2020_006.png b/2022_005_goldberg_v1_1/urbanonyme_2020_006.png
new file mode 100644
index 0000000000000000000000000000000000000000..51a47e69f6dfa968894aea7cb23787cef3f66dc9
Binary files /dev/null and b/2022_005_goldberg_v1_1/urbanonyme_2020_006.png differ
diff --git a/2022_005_goldberg_v1_1/urbanonyme_2020_007.png b/2022_005_goldberg_v1_1/urbanonyme_2020_007.png
new file mode 100644
index 0000000000000000000000000000000000000000..5ca3ae74eec008cd6f40045a0e0e30db32ec49d4
Binary files /dev/null and b/2022_005_goldberg_v1_1/urbanonyme_2020_007.png differ
diff --git a/2022_005_goldberg_v1_1/urbanonyme_2020_008.png b/2022_005_goldberg_v1_1/urbanonyme_2020_008.png
new file mode 100644
index 0000000000000000000000000000000000000000..7a47caccee4acf3f7e2f99755cefe11f96258c93
Binary files /dev/null and b/2022_005_goldberg_v1_1/urbanonyme_2020_008.png differ
diff --git a/2022_005_goldberg_v1_1/urbanonyme_2020_009.png b/2022_005_goldberg_v1_1/urbanonyme_2020_009.png
new file mode 100644
index 0000000000000000000000000000000000000000..8fd68b3a3e4b9407a794ddb488185e7c9a371787
Binary files /dev/null and b/2022_005_goldberg_v1_1/urbanonyme_2020_009.png differ
diff --git a/2022_005_goldberg_v1_1/urbanonyme_2020_010.png b/2022_005_goldberg_v1_1/urbanonyme_2020_010.png
new file mode 100644
index 0000000000000000000000000000000000000000..a11271e44e4145eeb921ef8b71a8bab3858a0c1e
Binary files /dev/null and b/2022_005_goldberg_v1_1/urbanonyme_2020_010.png differ
diff --git a/2022_005_goldberg_v1_1/urbanonyme_2020_011.png b/2022_005_goldberg_v1_1/urbanonyme_2020_011.png
new file mode 100644
index 0000000000000000000000000000000000000000..e7aecbb938807a5c5f9cc39cecc30b724780b0b0
Binary files /dev/null and b/2022_005_goldberg_v1_1/urbanonyme_2020_011.png differ
diff --git a/2022_005_goldberg_v1_1/urbanonyme_2020_012.png b/2022_005_goldberg_v1_1/urbanonyme_2020_012.png
new file mode 100644
index 0000000000000000000000000000000000000000..09c93a523fef7a851abd4b82e7b3d286081ddfb7
Binary files /dev/null and b/2022_005_goldberg_v1_1/urbanonyme_2020_012.png differ
diff --git a/2022_005_goldberg_v1_1/urbanonyme_2020_013.png b/2022_005_goldberg_v1_1/urbanonyme_2020_013.png
new file mode 100644
index 0000000000000000000000000000000000000000..851ab363c7af786ca7bb6bc929da2b5c1956964e
Binary files /dev/null and b/2022_005_goldberg_v1_1/urbanonyme_2020_013.png differ
diff --git a/2022_005_goldberg_v1_1/urbanonyme_2020_014.png b/2022_005_goldberg_v1_1/urbanonyme_2020_014.png
new file mode 100644
index 0000000000000000000000000000000000000000..0ee5c033900af6ce2c74e611148b08c74ca10ebb
Binary files /dev/null and b/2022_005_goldberg_v1_1/urbanonyme_2020_014.png differ
diff --git a/2022_005_goldberg_v1_1/urbanonyme_2020_015.png b/2022_005_goldberg_v1_1/urbanonyme_2020_015.png
new file mode 100644
index 0000000000000000000000000000000000000000..3697649173c232d02c17353b98a2b8198fad5ea2
Binary files /dev/null and b/2022_005_goldberg_v1_1/urbanonyme_2020_015.png differ
diff --git a/2022_005_goldberg_v1_1/urbanonyme_2020_v1_1.pdf b/2022_005_goldberg_v1_1/urbanonyme_2020_v1_1.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..8b00360686d8dea975500fe2f9cc8c07d423e41d
Binary files /dev/null and b/2022_005_goldberg_v1_1/urbanonyme_2020_v1_1.pdf differ
diff --git a/2022_005_goldberg_v1_1/urbanonyme_2020_v1_1.xml b/2022_005_goldberg_v1_1/urbanonyme_2020_v1_1.xml
new file mode 100644
index 0000000000000000000000000000000000000000..266005561fc055663c3c72d28752f938a732ccfb
--- /dev/null
+++ b/2022_005_goldberg_v1_1/urbanonyme_2020_v1_1.xml
@@ -0,0 +1,2169 @@
+<?xml-model href="https://www.zfdg.de/sites/default/files/schema/tei_zfdg.rnc" type="application/relax-ng-compact-syntax"
+ ?>
+<TEI xmlns="http://www.tei-c.org/ns/1.0" xmlns:html="http://www.w3.org/1999/html" xmlns:tei="http://www.tei-c.org/ns/1.0" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:xlink="http://www.w3.org/1999/xlink">
+ <teiHeader>
+ <fileDesc>
+ <titleStmt>
+ <title>
+ <biblStruct>
+ <analytic>
+ <title level="a">Kontextsensitive Entscheidungsfindung zur automatisierten
+ Identifizierung und Clusterung deutschsprachiger Urbanonyme</title>
+ <respStmt>
+ <resp ref="http://id.loc.gov/vocabulary/relators/aut">Author</resp>
+ <persName role="author">
+ <forename>Jan Michael</forename>
+ <surname>Goldberg</surname>
+ <email>jan.goldberg@wiwi.uni-halle.de</email>
+ <idno type="gnd">1240406630</idno>
+ <idno type="orcid">0000-0002-4817-4283</idno>
+ <affiliation>Martin-Luther-Universität Halle Wittenberg, Lehrstuhl für empirische Makroökonomik</affiliation>
+ </persName>
+
+ </respStmt>
+ <idno type="doi">10.17175/2022_005</idno>
+ <idno type="ppn">1817560271</idno>
+ <idno type="zfdg">2022.005</idno>
+ <idno type="url">https://www.zfdg.de/node/339</idno>
+ <date when="2022-10-10">10.10.2022</date>
+ </analytic>
+ <monogr>
+ <title level="j">Zeitschrift für digitale Geisteswissenschaften</title>
+ <respStmt>
+ <resp>Publiziert von</resp>
+ <orgName role="marc_pbl">Herzog August Bibliothek</orgName>
+ </respStmt>
+ <respStmt>
+ <resp ref="http://id.loc.gov/vocabulary/relators/dtm">Transformation der Word Vorlage nach TEI</resp>
+ <persName>
+ <surname>Baumgarten</surname>
+ <forename>Marcus</forename>
+ <idno type="gnd">1192832655</idno>
+ <idno type="orcid">0000-0003-0801-9462</idno>
+ </persName>
+ </respStmt>
+ <availability status="free">
+ <p>Available at <ref target="https://www.zfdg.de">https://www.zfdg.de</ref>
+ </p>
+ </availability>
+ <biblScope unit="year">2022</biblScope>
+ <biblScope unit="artikel">05</biblScope>
+ </monogr>
+ </biblStruct>
+ </title>
+ </titleStmt>
+ <editionStmt>
+ <edition>Elektronische Ausgabe nach TEI P5</edition>
+ </editionStmt>
+ <publicationStmt>
+ <distributor>
+ <name>
+ <orgName>Herzog August Bibliothek Wolfenbüttel</orgName>
+ </name>
+ </distributor>
+ <idno type="doi">10.17175/zfdg.01</idno>
+ <idno type="ppn">0819494402</idno>
+ <authority>
+ <name>Herzog August Bibliothek</name>
+ <address>
+ <addrLine>Lessingplatz 1</addrLine>
+ <addrLine>38304 Wolfenbüttel</addrLine>
+ </address>
+ </authority>
+ <authority>
+ <name>Forschungsverbund Marbach Weimar Wolfenbüttel</name>
+ <address>
+ <addrLine>Burgplatz 4</addrLine>
+ <addrLine>99423 Weimar </addrLine>
+ </address>
+ </authority>
+ <availability status="free">
+ <p> Sofern nicht anders angegeben </p>
+ <licence target="http://creativecommons.org/licenses/by/4.0/">CC BY SA 4.0</licence>
+ </availability>
+ <availability status="free">
+ <p> Available at <ref target="workID">https://www.zfdg.de; (c)
+ Forschungsverbund MWW</ref>
+ </p>
+ </availability>
+ </publicationStmt>
+ <sourceDesc>
+
+ <p>Einreichung als Fachartikel in der ZfdG durch die Autor*innen</p>
+ </sourceDesc>
+ </fileDesc>
+ <encodingDesc>
+ <editorialDecl>
+ <p>Transformation der WORD-Vorlage nach XML/TEI-P5 durch TEI-Oxgarage und
+ XSLT-Skripten</p>
+ </editorialDecl>
+ <editorialDecl>
+ <p xml:lang="de">Lektorat des Textes durch die Redaktion in Person von <persName>Martin Wiegand</persName>.</p>
+ <p>Medienrechte liegen bei den Autor*innen</p>
+ <p>All links checked<date when="2022-08-03">03.08.2022</date>
+ </p>
+ </editorialDecl>
+ </encodingDesc>
+ <profileDesc>
+ <creation>Einreichung als Artikel der Zeitschrift für digitale
+ Geisteswissenschaften</creation>
+ <langUsage>
+ <language ident="de">Text auf Deutsch</language>
+ <language ident="de">Abstract auf Deutsch</language>
+ <language ident="en">Abstract auf Englisch</language>
+ </langUsage>
+ <textClass>
+ <keywords scheme="gnd">
+ <term>Historische Geografie<ref target="4025103-2"/>
+ </term>
+ <term>Cluster-Analyse<ref target="4070044-6"/>
+ </term>
+ <term>Lokalisation<ref target="4195351-4"/>
+ </term>
+ <term>Kontextbezogenes System<ref target="4739720-2"/>
+ </term>
+ <term>Klassifikation<ref target="4030958-7"/>
+ </term>
+ </keywords>
+ </textClass>
+ </profileDesc>
+ <revisionDesc>
+
+ <change when="2023-10-17" n="1.1" status="published">
+
+ <p>Kleinere Änderungen im Text; Präzisierung des Begriffs »Cluster« zu »(Orts-)Cluster«; Ergänzung sowie Streichung in der Bibliografie.</p>
+
+ </change>
+
+ </revisionDesc>
+ </teiHeader>
+ <text>
+ <body>
+ <div>
+ <div type="abstract">
+ <argument xml:lang="de">
+ <p>Viele historische Quellen enthalten zahlreiche Ortsangaben,
+ deren manuelle Zuordnung viele Ressourcen bindet. Um hier Abhilfe zu schaffen wird
+ ein Algorithmus beschrieben, mit dem solche Urbanonyme automatisiert geokodiert
+ werden können. Ebenso ist es möglich, die Orte entsprechend ihrer gemeinsamen
+ historischen Verwaltungszugehörigkeit zu clustern. Probleme wie gleiche Namen bei
+ Ortsbezeichnungen werden vor allem durch eine Einbeziehung weiterer Informationen
+ desselben Kontextes (derselben Quelle) gelöst. Eine Validierung geschieht anhand von
+ etwa 3,4 Millionen überwiegend deutschsprachigen Ortsangaben aus der genealogischen
+ Datenbank <hi rend="italic">GEDBAS</hi>. Zusammenfassend lassen sich etwa drei von
+ vier relevanten Ortsangaben identifizieren und lokalisieren. Ãœber 90 Prozent der
+ identifizierten Ortsangaben können ihrer historischen Provinz zugeordnet werden.</p>
+ </argument>
+ <argument xml:lang="en">
+ <p>Many historical sources contain numerous names of places, the
+ manual assignment of which ties up a lot of resources. To simpliy this, an algorithm
+ is described with which such urbanonyms can be geocoded automatically. It is also
+ possible to cluster the places according to their common historical administrative
+ affiliation. Problems such as identical terms for place names are solved primarily
+ by including further information from the same context (same source). A validation
+ is done on the basis of about 3.4 million mostly German-language place names from
+ the genealogical database <hi rend="italic">GEDBAS</hi>. In summary, about three out
+ of four relevant place names can be identified and localised. More than 90 percent
+ of the identified place names can be assigned to their historical province.</p>
+ </argument>
+ </div>
+ <div type="chapter">
+ <head>1. Einleitung</head>
+ <p>Orte werden tagtäglich in vielen
+ Applikationen identifiziert und lokalisiert.<note type="footnote"> Die Identifizierung beschreibt die Zuordnung zu
+ einem Identifikator, der einem physischen Ort zugeordnet ist. Dagegen
+ umfasst die Lokalisierung die gelungene geographische Verortung des
+ identifizierten Ortes.</note> Der Bahnticketautomat, das
+ Navigationsgerät im Auto oder die Suchmaschine im Internet stellen dafür nur einige
+ willkürliche Beispiele dar. Das Prinzip dahinter ist vielfach aber gleich: Nach der
+ Eingabe eines Orts oder mindestens eines Teils davon schlägt die Applikation einen
+ oder mehrere auszuwählende(n) Orte vor. Die letztendliche Auswahl kann vom Menschen
+ getroffen werden. Steht jedoch kein Mensch zur Verfügung, um eine abschließende
+ Auswahl zu treffen, muss die Entscheidung auf zuvor definierten Kriterien beruhen.
+ Durch Dopplungen, Ähnlichkeiten und Variationen von Ortsnamen ist dies jedoch kein
+ triviales Unterfangen.</p>
+ <p>In Deutschland (und Europa) gibt es
+ beispielsweise zahlreiche Orte namens Neustadt. Allein 36 davon sind in der
+ Arbeitsgemeinschaft <term type="figure">Neustadt in Europa</term>
+ zusammengefasst.<note type="footnote"> <ref type="bibliography" target="#working-group_neustadt_2021">Working Group Neustadt in Europa (Hg.) 2021</ref>.</note> Hinzu kommt, dass
+ etliche Stadtteile diese Bezeichnung tragen. Werden die historischen, heute nicht
+ mehr genutzten Bezeichnungen inkludiert, sind es nochmals mehr. Das kann zum einen
+ darin begründet sein, dass die Ortsbezeichnungen heute einfach nicht mehr in
+ Verwendung sind, weil es den Ort entweder nicht mehr gibt oder aber eine Umbenennung
+ stattgefunden hat.<note type="footnote"> <ref type="bibliography" target="#zedlitz_survey_2014">Zedlitz / Luttenberger 2014</ref>, S. 218–231.</note> Zum anderen können die
+ historischen Ortsangaben aber auch einen Ort beschreiben, dessen Relevanz heute
+ nicht mehr ausreichend ist, um diesen durch eine gesonderte Bezeichnung zu würdigen
+ – ohne, dass dieser gänzlich verschwunden wäre. Möglicherweise ist der Ort auch in
+ einem übergeordneten aufgegangen; kleine Siedlungsformen, wie beispielsweise Weiler,
+ verschwanden im Laufe der letzten Jahrhunderte. Die Herausforderungen, die sich
+ heute aus der Lokalisierung von Ortsnamen ergeben, sind bei der Zuordnung
+ historischer Bezeichnungen – im Weiteren als Urbanonyme<note type="footnote"> Der Begriff der Urbanonyme
+ beschreibt dabei Siedlungsstrukturen (z. B. Städte, Dörfer) und stellt somit
+ eine Unterkategorie der Toponyme da. Er wird im Folgenden synonym zum
+ Begriff der Ortsbezeichnung verwendet.</note> bezeichnet – also umso
+ größer. </p>
+ <p>Historische Ortsangaben stehen
+ allerdings selten für sich allein, sondern sind von Kontextinformationen umgeben.
+ Eingebettet in einen Fließtext kann sich aus den weiteren Informationen ergeben, um
+ welchen Ort es sich handelt. Beispielsweise können in einem Adressbuch andere
+ Ortsangaben oder die Angabe einer übergeordneten Gebietskörperschaft vorhanden sein.
+ Diese als Kontext bezeichneten Informationen können zur Identifizierung genutzt
+ werden. Nachfolgend kann auf dieser Basis eine geographische Lokalisierung des Orts
+ angestellt werden. Im Kontext dieser Arbeit meint Lokalisierung eine Ortsbestimmung,
+ die Objekte zu einer Adresse im physischen Raum der Erdoberfläche zuordnet.<note type="footnote"> Die Bestimmung der
+ Position wird heute oftmals satellitengestützt realisiert (vgl. <ref type="bibliography" target="#gentile_techniques_2013">Gentile et al.
+ (Hg.) 2013</ref>). Diese Möglichkeit setzt voraus, dass das zu lokalisierende
+ Objekt (1.) bekannt ist und sich (2.) an der zu lokalisierenden Position
+ befindet. Historische Ortsangaben hingegen beschreiben Positionen von
+ (unbekannten) Objekten zu vergangenen Zeitpunkten. Deshalb sind moderne
+ Möglichkeiten der Lokalisierung auf diese Problematik nicht
+ anwendbar.</note> Eine gesonderte, automatisierte Lösung zur Identifikation
+ und Lokalisierung (speziell deutschsprachiger) historischer Urbanonyme ist bis dato
+ nicht bekannt. Diese Lücke wird durch den vorliegenden Artikel geschlossen, indem
+ ein Algorithmus als Lösung vorgeschlagen wird, der historische Ortsangaben<note type="footnote"> Als <hi rend="italic">historische Ortsangaben</hi> werden im
+ Folgenden solche Bezeichnungen beschrieben, die in deutscher Sprache einen
+ Ort im deutschsprachigen Raum im Zeitfenster ab dem 17. Jahrhundert beschreiben. In
+ Abgrenzung dazu finden Ortsbezeichnungen aus antiken und mittelalterlichen
+ Quellen keine Verwendung.</note> kontextsensitiv lokalisiert. Eine
+ Ãœbersicht der Begrifflichkeiten ist in <ref type="graphic" target="#urbanonyme_2020_001">Abbildung 1</ref>
+ vorhanden.</p>
+ <p>Für viele wissenschaftliche
+ Fragestellungen reicht allein die Lokalisierung der Ortsangaben jedoch nicht aus.
+ Vielmehr ist es auch wichtig, die (historische) administrative Zugehörigkeit der
+ Orte zu ermitteln und alle zusammengehörigen Ortsangaben zu clustern. Darum wird mit
+ dem Algorithmus auch eine Methode bereitgestellt, mit der Orte über die
+ administrative Zugehörigkeit zu einem definierten Zeitpunkt geclustert werden
+ können. Der Algorithmus wird primär mit Hilfe von Urbanonymen aus genealogischen
+ GEDCOM-Dateien<note type="footnote">
+ Sie enthalten oftmals sehr viele Ortsangaben zu Lebensereignissen wie
+ Geburten oder Hochzeiten. GEDCOM-Dateien stellen dabei den gängigen Standard
+ im Austausch genealogischer Informationen dar (vgl. <ref type="bibliography" target="#gellatly_reconstructing_2015">Gellatly 2015</ref>, S. 112;
+ <ref type="bibliography" target="#harviainen_genealogy_2018">Harviainen / Björk 2018</ref>). </note> aus der Datenbank <bibl>
+ <title type="desc">Genealogische Datenbasis</title>
+ </bibl> (GEDBAS) getestet, soll aber
+ auch auf andere Quellen adaptiert werden können. Damit wird ebenfalls einem
+ Vorschlag Gellatlys nachgekommen, eine Software zur Geokodierung von Ortsangaben zu
+ entwickeln.<note type="footnote">
+ <ref type="bibliography" target="#gellatly_reconstructing_2015">Gellatly 2015</ref>, S. 118.</note>
+ </p>
+ <p>Im folgenden Kapitel werden zunächst
+ verschiedene bestehende Lösungsansätze betrachtet, auf deren Basis die Entwicklung
+ des Algorithmus stattfindet. Danach wird der entwickelte Algorithmus in der
+ Programmiersprache Python umgesetzt und am Beispiel von GEDCOM-Dateien aus der
+ GEDBAS validiert. Abschließend erfolgt eine Zusammenfassung.</p>
+ <figure>
+ <graphic xml:id="urbanonyme_2020_001" url="Medien/urbanonyme_2020_001.png">
+ <desc>
+ <ref target="#abb1">Abb. 1</ref>: Übersicht über Begrifflichkeiten und Zusammenhänge.

+ [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_001"/>
+ </desc>
+ </graphic>
+ </figure>
+ </div>
+ <div type="chapter">
+ <head>2. Identifizierung und Lokalisierung von Urbanonymen</head>
+ <p>Die Identifizierung beschreibt die
+ Zuordnung eines Urbanonyms (z. B. ›Berlin‹) zu einer physisch existierenden Entität
+ – einem Ort (z. B. der Hauptstadt Berlin der Bundesrepublik Deutschland). Die
+ Lokalisierung hingegen besteht in der Zuordnung von Koordinaten zu diesem Ort. Auch
+ wenn die Lokalisierung das wesentliche Ziel darstellt, so liegt in der
+ vorhergehenden Identifizierung die maßgebliche Herausforderung. Das ist dadurch
+ bedingt, dass zu nahezu allen (identifizierten) Orten die geographischen Koordinaten
+ leicht zu ermitteln sind, die eindeutige Identifizierung jedoch durch verschiedene
+ historisch bedingte Faktoren erschwert wird.</p>
+ <p>Im Folgenden wird der Stand der
+ Technik verschiedener Teilaspekte dieser Herausforderung beschrieben. Zunächst wird
+ erläutert, wie der Kontext zur Entscheidungsfindung beitragen kann. Danach werden
+ kurz relevante Suchalgorithmen sowie Methoden der Ähnlichkeitsanalyse aufgegriffen.
+ Da eine Identifizierung von Urbanonymen nur unter Hinzunahme (historischer)
+ Ortsverzeichnisse möglich ist, finden auch diese Beachtung. Abschließend wird in die
+ Struktur von GEDCOM-Daten eingeführt, die in dieser Studie zur Validierung des
+ Algorithmus dienen.</p>
+ <div type="subchapter">
+ <head>2.1 Kontextsensitive Entscheidungsfindung</head>
+ <p>Das oben angeführte Beispiel Berlins
+ zeigt die Problematik deutlich auf: Neben der Hauptstadt könnte ebenso eine andere
+ Entität, z. B. das Land Berlin der Bundesrepublik Deutschland oder der Ortsteil
+ Berlin der schleswig-holsteinischen Gemeinde Seedorf, gemeint sein.<note type="footnote"> In dem Fall würde es
+ sich bei der Ortsangabe um ein Choronym, nicht um eine Urbanonym,
+ handeln.</note> Ohne weitere Informationen, worauf sich die Ortsangabe
+ bezieht oder in welchem Zusammenhang diese genannt wird, kann eine Identifizierung
+ nicht eindeutig vorgenommen werden. Die Informationen im Zusammenhang der Verwendung
+ eines Wortes werden dabei als ›Kontext‹ bezeichnet. Nach Dey und Abowd ist Kontext
+ aus informationstechnischer Sicht jede Information, die zur Charakterisierung der
+ Situation einer Entität genutzt werden kann.<note type="footnote"> <ref type="bibliography" target="#abowd_context-awareness_1999">Abowd / Dey 1999</ref>, S. 1, 3-4.</note> Systeme,
+ die diesen Kontext nutzen, werden als ›kontextsensitiv‹ bezeichnet.<note type="footnote"> <ref type="bibliography" target="#sitou_requirements_2009">Sitou 2009</ref>, S. 28,
+ 123.</note> Kontextsensitive Systeme bedingen also eine Flexibilität in
+ der Ausführung eines Prozesses. Der Kontext als externer Einfluss kann dazu führen,
+ dass der interne Prozess der Informationsverarbeitung angepasst wird.<note type="footnote"> <ref type="bibliography" target="#rosemann_process_2006">Rosemann / Recker
+ 2006</ref>, S. 149.</note> Ein Beispiel dafür ist die Anzeige der
+ Wettervorhersage in Abhängigkeit der Position oder die Veränderung der
+ Bildschirmhelligkeit in Abhängigkeit der Umgebungsbeleuchtung. Auch in CARS (Context
+ Based Recommendation Systems) werden Nutzer*innen auf Basis der ihnen verfügbaren
+ Kontextinformationen in der Entscheidungsfindung unterstützt.<note type="footnote"> <ref type="bibliography" target="#zheng_integrating_2019">Zheng et al. 2019</ref>, S.
+ 2453.</note> Daneben ist eine eigenständige Entscheidung zwischen mehreren
+ konkreten Alternativen ohne menschliches Zutun auf Basis des Kontextes möglich. </p>
+ <p>Bei der Lokalisierung ist eine
+ Entscheidung notwendig, um die Verbindung zwischen einer konkreten Ortsbezeichnung
+ und einem Ort zu definieren. Solche Entscheidungen können (in Anlehnung an einen
+ binären Klassifikator) richtig oder falsch sein. Jedoch kann auch keine Entscheidung
+ getroffen werden – und auch dieses kann richtig oder falsch sein. Richtig kann eine
+ nicht getroffene Entscheidung für einen Ort beispielsweise sein, wenn die
+ Ortsbezeichnung ›John Michael‹ lautet und kein Urbanonym darstellt, sondern – wie im
+ Beispiel – womöglich aus einem Eingabefehler resultiert und einen Vornamen darstellt
+ (TN). Diese Konstellationen sind in <ref type="intern" target="#tab01">Tabelle 1</ref> dargestellt. Dasselbe Schema ist auf
+ die Lokalisierung und die nachfolgende regionale Klassifizierung anwendbar. Ziel ist
+ es, möglich viele T*-Zuordnungen zu erreichen, gleichzeitig aber die F*-Rate niedrig
+ zu halten.</p>
+ <table>
+ <row>
+ <cell/>
+ <cell>Identifizierung korrekt</cell>
+ <cell>Identifizierung nicht korrekt</cell>
+ </row>
+ <row>
+ <cell>Identifizierung erfolgt</cell>
+ <cell>True
+ positive (TP)</cell>
+ <cell>False
+ positive (FP)</cell>
+ </row>
+ <row>
+ <cell>Identifizierung nicht erfolgt</cell>
+ <cell>True
+ negative (TN)</cell>
+ <cell>False
+ negative (FN)</cell>
+ </row>
+
+ <trailer xml:id="tab01">
+ <ref type ="intern" target="#tab1">Tab. 1</ref>: Konfusionsmatrix

+ zur Identifizierung von Ortsbezeichnungen in Anlehnung an Fawcett. [Fawcett 2006, S.

+ 862]<ref type="graphic"
+ target="#urbanonyme_2020_t1"/>
+ </trailer>
+ </table>
+ <p>Um es am Beispiel Berlins
+ auszudrücken: So würde in einer Liste der Bundesländer eher die Entität des Landes
+ aufgegriffen, in einer Liste aller Hauptstädte jedoch die Entität Berlins als
+ Hauptstadt Deutschlands. Der Kontext würde hier den Schluss zulassen, ob es sich um
+ das Land oder die Stadt handelt. Diese Schlussfolgerung ist das Ergebnis einer
+ Heuristik: Alle Werte in der Liste beschreiben Länder, also ist es wahrscheinlich,
+ dass der letzte Wert auch ein Land ist. Jedoch kann der Wert auch kein Land
+ darstellen, wodurch die Schlussfolgerung falsch wäre (FP). Heuristiken garantieren
+ keine richtigen Ergebnisse,<note type="footnote"> <ref
+ type="bibliography" target="#feigenbaum_computers_1963">Feigenbaum / Feldman (Hg.) 1963</ref>, S. 6.</note> sie
+ dienen der Findung einer wahrscheinlich korrekten Lösung unter begrenztem Wissen und
+ wenig Zeit.<note type="footnote"> Vgl.
+ <ref
+ type="bibliography" target="#gigerenzer_heuristics_1999">Gigerenzer / Todd (Hg.) 1999</ref>, S. 147.</note> Insofern sind
+ kontextsensitive Entscheidungen, wenn der Kontext die Entscheidung nicht
+ eineindeutig zulässt, heuristische Verfahren. Um eine Heuristik im
+ Entscheidungsprozess eines technischen Systems einzusetzen, ist ihre Formalisierung
+ notwendig. Eine programmtechnische Formalisierung der Heuristik führt in der Folge
+ zu einem (heuristischen) Algorithmus.</p>
+ <p>Um den Kontext einer Ortsbezeichnung
+ nun für die Zuordnung zu einer Entität zu verwenden, müssen die Heuristiken
+ definiert werden, die die Entscheidungsfindung beeinflussen. Zandhuis et al. nennen
+ drei Möglichkeiten der Einbindung des Kontextes: </p>
+ <list type="ordered">
+ <item>den Ort, an dem die Ortsangabe erstellt wurde, </item>
+ <item>eine Gebietszugehörigkeit und </item>
+ <item>die Zeit, in der die Quelle kreiert wurde in Zusammenhang mit der Information,
+ wann ein Ort wie bezeichnet wurde, da die Bezeichnung temporalen Schwankungen
+ unterliegen kann.<note type="footnote"> <ref
+ type="bibliography" target="#zandhuis_toponyms_2015">Zandhuis et al. 2015</ref>, S. 36.</note>
+ </item>
+ </list>
+ <p>Insbesondere bei Sekundärquellen ist
+ der Ort der (Primär-)Quellenerstellung nicht relevant oder bekannt. Auch
+ Gebietsangaben sind nicht immer vorhanden. Ebenso verhält es sich mit den temporalen
+ Informationen. Zudem kann in Sekundärquellen eine sprachliche Anpassung des
+ Ortsnamens (an die Schreibweise zur Zeit der Erstellung der Sekundärquelle)
+ stattgefunden haben. </p>
+ <p>Aufgrund dieser Schwierigkeiten sind
+ die drei genannten Punkte für eine Identifizierung nicht ausreichend. Es lassen sich
+ jedoch andere Kontextinformationen finden: Der Kontext von Ortsbezeichnungen kann
+ aus weiteren Ortsangaben bestehen, die möglicherweise in einem Zusammenhang stehen.
+ Gegebenenfalls sind im Kontext auch konkrete Angaben zur geographischen Distanz
+ zwischen den Entitäten, zur gemeinsamen administrativen Zugehörigkeit oder einer
+ sonstigen Beziehung vorhanden. Zudem können temporale Angaben im Kontext die
+ Identifizierung der Ortsangaben unterstützen. Aber nicht nur die Nennung von Orten,
+ sondern auch die Personennamen kann relevant sein: Die Häufigkeit von Vornamen variiert
+ über die Zeit, sodass hierüber eine Schätzung des Geburtsjahres – und somit eine
+ zeitliche Verortung der Ortsbezeichnung – vorgenommen werden kann.<note type="footnote"> <ref
+ type="bibliography" target="#gallagher_estimating_2008">Gallagher / Chen 2008</ref>.</note>
+ Wichtiger jedoch erscheint die regionale Dichte und Häufigkeit von Personennamen: Die
+ Verwendung von Nachnamen ist oftmals geografisch nicht gleichverteilt.<note type="footnote"> Vgl. <ref
+ type="bibliography" target="#seibicke_personennamen_1982">Seibicke 1982</ref>,
+ S. 148.</note> In <ref type="graphic" target="#urbanonyme_2020_002">Abbildung 2</ref> sind
+ beispielhaft die relative und absolute Verteilung des Nachnamens ›Hinse‹ abgebildet.
+ Es ist eine erhöhte Dichte im westfälischen Raum zu erkennen.<note type="footnote"> Die Karte wurde mit <ref target="https://geogen.stoepel.net/legacy.html?">Geogen</ref> erzeugt und basiert auf
+ etwa 35 Millionen Telefonbucheinträgen. Stöpel 2021b.</note> Demzufolge
+ ist also wahrscheinlicher, dass der Name in Kombination mit Orten im westfälischen
+ Raum genannt wird.</p>
+ <figure>
+ <graphic xml:id="urbanonyme_2020_002" url="Medien/urbanonyme_2020_002.png">
+ <desc>
+ <ref target="#abb2">Abb. 2</ref>: Relative (links) und

+ absolute (rechts) Verteilung des Nachnamens Hinse. [Goldberg 2022, erstellt mit

+ Geogen Deutschland, Stöpel 2021a]<ref type="graphic" target="#urbanonyme_2020_002"/>
+ </desc>
+ </graphic>
+ </figure>
+ <p>Auch bei der Vornamensgebung sind in
+ Deutschland regionale Unterschiede zu erkennen,<note type="footnote"> <ref
+ type="bibliography" target="#gesellschaft_vornamen_2019">Gesellschaft für deutsche Sprache e. V. (Hg.)
+ 2019</ref>.</note> was teilweise auf unterschiedliche Präferenzen in der
+ Taufnamensgebung verschiedener Konfessionen zurückzuführen ist.<note type="footnote"> Vgl. <ref
+ type="bibliography" target="#seibicke_personennamen_1982">Seibicke 1982</ref>, S.
+ 150.</note>
+ </p>
+ </div>
+ <div type="subchapter">
+ <head>2.2 Suchalgorithmen und Ähnlichkeitsanalyse</head>
+ <p>Alle (vormals) existierenden Orte
+ können in einer Liste dargestellt werden. Sie stellen eine endliche Menge dar. Da es
+ jedoch hunderttausende Orte gibt (oder gab), von denen jeweils einer ausgewählt
+ werden soll, ist anzunehmen, dass die Auswahl eines Suchalgorithmus erhebliche
+ Auswirkung auf die Performance hat. Zur Suche in Listen existieren verschiedenste
+ Algorithmen, die oftmals an ihre jeweilige Anwendung angepasst werden. Da es sich
+ bei Ortsbezeichnungen um Zeichenketten handelt, sind hier insbesondere
+ String-Matching-Algorithmen relevant. Die Namen der Orte fungieren dabei als
+ Eigenschaft der Entität, die mit der Ortsbezeichnung verglichen werden kann.</p>
+ <p>Suchalgorithmen können grundlegend in
+ einfache und informierte Suchen unterteilt werden. Im Gegensatz zu den einfachen
+ Suchen ist bei den informierten Suchen ein Wissen über den Suchraum vorhanden.<note type="footnote"> Vgl. <ref
+ type="bibliography" target="#clarke_principles_2009">Clarke et al.
+ 2009</ref>, S. 34.</note> Bei einer gegebenen Liste von Orten findet ein
+ einfaches Suchverfahren Verwendung, bei der Auswahl eines Suchalgorithmus sind
+ dagegen insbesondere Laufzeit und Genauigkeit von Interesse: Während bei einer
+ linearen Suche in Listen jedes Element betrachtet werden muss, ist bei der binären
+ Suche nur die logarithmische Anzahl von Vergleichen durchzuführen. Es zeigt sich,
+ dass bei der Verarbeitung vieler Urbanonyme soweit wie möglich auf lineare Suchen
+ verzichtet werden sollte; stattdessen ist der Einsatz binärer Suchalgorithmen
+ angebracht. Hierzu ist vorbereitend eine alphabetische Sortierung möglicher Zielorte
+ durchzuführen.</p>
+ <p>Ortsbezeichnungen können jedoch
+ Rechtschreibfehler wie vertauschte Zeichen aufweisen. Ebenso kann die Schreibweise
+ von Orten im Zeitverlauf einer Variation unterliegen, ohne dass eine gänzliche
+ Umbenennung erfolgt ist. Auch wenn die Suche keine eindeutigen Treffer hervorbringt,
+ kann über einen Vergleich der Ähnlichkeit eine Identifizierung erfolgen. Zum
+ Vergleich der Ähnlichkeit gibt es verschiedene Maße. Ein übliches Maß stellt die
+ Levenshtein-Distanz dar, eine Metrik, mit der Schritte der Veränderung zwischen
+ Wörtern gezählt werden.<note type="footnote"> <ref
+ type="bibliography" target="#levenstejn_codes_1966">Levenštejn 1966</ref>.</note> Die Distanz ist bei
+ identischen Zeichenketten 0 und beträgt maximal die Länge des längeren Strings. Hier
+ besteht die Herausforderung, einen Wert auszuwählen, der für den jeweiligen
+ Vergleich als plausibel gilt,<note type="footnote"> Es sind keine allgemein üblichen Toleranzkriterien bei
+ dem Vergleich von Ortsstrings bekannt. Möglicherweise ist eine solche Art
+ der Ähnlichkeitsanalyse bei Orten nicht besonders zielführend, da viele Orte
+ sehr gleichklingend sind und eine Levenshtein-Distanz von 2 bereits
+ wesentliche Veränderungen herbeiführen kann.</note> wobei ein Bezug auf
+ die Länge der gesuchten Zeichenkette angebracht sein kann.<note type="footnote"> Vgl. <ref
+ type="bibliography" target="#list_distanz_2010">List 2010</ref>, S.
+ 8.</note>
+ </p>
+ <p>Statt in einer Liste können Orte auch
+ in Bäumen strukturiert sein. Zur Optimierung des Suchverhaltens in diesen ist ein
+ informierter Ansatz möglich, der beispielsweise nur solche Pfade mit definierten
+ Eigenschaften durchsucht.</p>
+ </div>
+ <div type="subchapter">
+ <head>2.3 Historische Orte und Urbanonyme</head>
+ <p>Um überhaupt Orte zu haben, die als
+ Entitäten dienen und einem Vergleich mit der Ortsbezeichnung zugefügt sind, ist die
+ Auswahl eines Ortsverzeichnisses eine notwendige Bedingung. Im Weiteren wird dazu
+ das <bibl>
+ <title type="desc">Geschichtliche Orts-Verzeichnis</title>
+ </bibl> (GOV) des Vereins
+ für Computergenealogie Verwendung finden.<note type="footnote"> Das GOV ist nicht das einzige Verzeichnis, das
+ historische Ortsangaben zusammengeführt. Daneben gibt es verschiedene
+ Ortslexika. Ein online verfügbares Beispiel stellt das <ref target="https://hov.isgv.de/">Historische
+ Ortsverzeichnis von Sachsen</ref> dar (vgl. <ref
+ type="bibliography" target="#institut_ortsverzeichnis_2020">Institut für sächsische
+ Geschichte und Volkskunde (Hg.) 2020</ref>). Für den gesamten deutschsprachigen
+ Raum ist das GOV jedoch die einzige digitale, klar strukturierte Sammlung
+ historischer Ortsangaben. Zudem unterliegt das Mini-GOV einer Creative
+ Common Lizenz und kann deshalb in diesem Rahmen Verwendung
+ finden.</note> Dieses enthält etwa 1,2 Millionen Objekte<note type="footnote"> Diese Objekte sind jeweils
+ sogenannten Typen zugeordnet. Die Typen beschreiben nicht nur Urbanonyme,
+ sondern auch politische, kirchliche oder gerichtliche Verwaltungen; auch
+ geographische Objekte oder solche zum Verkehrswesen sind
+ vorhanden.</note> in Europa.<note type="footnote"> <ref
+ type="bibliography" target="#verein_gov_2015">Verein für Computergenealogie e. V. (Hg.) 2015</ref>. Das
+ GOV erscheint insbesondere für den deutschsprachigen Raum geeignet.
+ </note> Das GOV wird ausgewählt, weil es besonders im deutschsprachigen Raum
+ viele historische Urbanonyme abbildet. Für andere Länder, beispielsweise die
+ Niederlande, gibt es zudem weitere ausführliche Portale.<note type="footnote"> Vgl. <ref
+ type="bibliography" target="#zandhuis_toponyms_2015">Zandhuis et al. 2015</ref>, S.
+ 24.</note>
+ </p>
+ <p>Zugang zum GOV kann eine externe
+ Anwendung auf zwei Arten erlangen. Zum einen über das sogenannte Mini-GOV worin
+ verschiedene Informationen zu Orten enthalten sind: Als <term type="dh">Uniform Resource Identifier</term> (URI) eines Ortes dient die sogenannte
+ GOV-Kennung. Daneben ist der Typ des Objekts vorhanden, gefolgt von dem aktuellen
+ Ortsamen (im Falle von früheren deutschen Siedlungsgebieten auch der letzte deutsche
+ Name). Auch der Staat, dem das Objekt angehört, sowie vier Angaben zur
+ administrativen Zuordnung werden angegeben.<note type="footnote"> Die administrative Zuordnung unterscheidet sich je
+ nach heutigem Staat. In Deutschland ist die adm. Zuordnung 1 auf das
+ Bundesland bezogen, die adm. Zuordnung 2 auf den Regierungsbezirk, die adm.
+ Zuordnung 3 auf den Kreis, Landkreis, Stadtkreis die kreisfreie Stadt oder
+ die Region und die adm. Zuordnung 4 auf die Stadt, Gemeinde, den Markt oder
+ Flecken.</note> Zudem ist die Postleitzahl vorhanden. Abschließend
+ folgen mit den Längen- und Breitengraden die Koordinaten des Objekts. Zum anderen
+ besteht die Möglichkeit über einen Webservice auf die Daten im GOV zuzugreifen.
+ Während durch das Mini-GOV nur die oben genannten Informationen zu einem Ort zur
+ Verfügung stehen, kann über den Webservice auf sämtliche Daten des GOV zugegriffen
+ werden (siehe <ref type="graphic" target="#urbanonyme_2020_003">Abbildung 3</ref>).<note type="footnote"> <ref
+ type="bibliography" target="#verein_gazetteer_2021a">Verein für Computergenealogie e.
+ V. (Hg.) 2021a</ref>.</note> Die Abfrage des Webservice ergibt ein assoziatives
+ Datenfeld (im Folgenden Dictionary), in dem verschiedene Informationen zum Ort
+ enthalten sind. Die Beschreibung der Zugehörigkeit zu übergeordneten Objekten
+ erfolgt im Key ›part-of‹. Das in <ref type="graphic" target="#urbanonyme_2020_003">Abbildung 3</ref>
+ dargestellte Beispiel enthält vier Zugehörigkeiten. Die Dauer der Zugehörigkeit kann
+ entweder über ›timespan‹ definiert sein. Im anderen Fall sind – wie im Beispiel –
+ Beginn und Ende gesondert definiert. Auch ist die GOV-ID des übergeordneten Objekts
+ enthalten. Das ermöglicht beispielsweise zusätzlich die administrativen
+ Zusammenhänge der Vergangenheit zu erfassen. Die dadurch entstehende Baumstruktur
+ ist implizit, da sie erst während der Suche erzeugt wird.</p>
+ <figure>
+ <graphic xml:id="urbanonyme_2020_003" url="Medien/urbanonyme_2020_003.png">
+ <desc>
+ <ref target="#abb3">Abb. 3</ref>: Auszug aus einer

+ GOV-Abfrage. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_003"/>
+ </desc>
+ </graphic>
+ </figure>
+ <p>Urbanonyme kommen in vielen Quellen
+ vor. Besonders konzentriert sind Urbanonyme in genealogischen Datenstrukturen zu
+ finden. Hierin sind es die zentralen Vitaldaten von Personen (Geburt bzw. Taufe,
+ Heirat und Tod bzw. Beerdigung), die oftmals auch mit einer Ortsbezeichnung versehen
+ sind. Durch die verwandtschaftlichen Verknüpfungen liegen zudem verschiedene
+ Kontextdaten vor (Personennamen, Zeiten, weitere Ortsangaben). Aufgrund der hohen
+ Informationsdichte werden im Zuge dieser Arbeit genealogische Daten in Form von
+ GEDCOM-Dateien zur Validierung des Algorithmus eingesetzt. Einzelne GEDCOM-Dateien
+ bestehen aus Text mit einer definierten Syntax. Eine Person wird beispielsweise wie
+ im nachfolgenden Beispiel definiert (siehe <ref type="graphic" target="#urbanonyme_2020_004">Abbildung 4</ref>). Verschiedenartige Informationen werden dabei mit
+ verschiedenen Tags gekennzeichnet. Standardmäßig definiert der Tag <code>PLAC</code> dabei eine Ortsangabe.<note type="footnote"> Neben dem Standard können
+ einzelne programmspezifische Tags entwickelt werden. Diesen ist ein
+ Unterstrich (›_‹) vorangestellt. So ist es prinzipiell möglich, weitere
+ ortsbezogene Tags zu entwickeln und anzuwenden. Hervorzuheben ist hierbei
+ insbesondere der Tag <code>_LOC</code>, über den ein eigener
+ Datensatz zu der Ortsangabe erstellt wird. Darin können u. a. Tags wie <code>_GOV</code> genutzt werden, über welchen direkt die
+ GOV-URI zugeordnet wird. Ãœber die Tags <code>LATI</code> und
+ <code>LONG</code> können zudem seit der GEDCOM-Version
+ 5.5.1 direkt Koordinatenangaben gemacht werden (vgl. <ref
+ type="bibliography" target="#gellatly_reconstructing_2015">Gellatly 2015</ref>, S. 118).
+ In der Validierung werden diese Tags nochmals aufgegriffen.</note> Diese
+ kann sich auf die oben genannten Ereignisse beziehen. Im Beispiel ist sie dem Tag
+ <code>DEAT</code> zugeordnet, beschreibt also den Ort des Todes.
+ Ortsangaben unter diesem Tag sollten die Verwaltungszugehörigkeit in aufsteigender
+ Reihenfolge enthalten und mit einem Komma voneinander getrennt werden,
+ beispielsweise: Stadt, Kreis, Bundesland, Land.<note type="footnote"> <ref
+ type="bibliography" target="#gellatly_reconstructing_2015">Gellatly 2015</ref>, S. 117.</note>
+ </p>
+ <figure>
+ <graphic xml:id="urbanonyme_2020_004" url="Medien/urbanonyme_2020_004.png">
+ <desc>
+ <ref target="#abb4">Abb. 4</ref>: Auszug einer
+ GEDCOM-Datei. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_004"/>
+ </desc>
+ </graphic>
+ </figure>
+ </div>
+ </div>
+ <div type="chapter">
+ <head>3. Entwicklung des (heuristischen) Algorithmus</head>
+ <p>Um historische Ortsangaben im
+ deutschsprachigen Raum zu identifizieren und nachfolgend lokalisieren zu können,
+ wird in diesem Abschnitt die Entwicklung eines Algorithmus beschrieben. In diesem
+ wird die Heuristik zur kontextbasierten Auswahl eines Orts formalisiert. Zunächst
+ wird die Metaheuristik erläutert, die dem zu entwickelnden Algorithmus zugrunde
+ liegt. Die einzelnen Unteraspekte der Metaheuristik werden danach ausführlicher
+ behandelt. Darunter fallen die Datenbereinigung, der Vergleich mit dem Mini-GOV, die
+ Realisierung einer Ähnlichkeitserkennung, die Hinzuziehung von Kontextdaten und
+ deren Alternativen sowie die Ermittlung historischer administrativer
+ Zugehörigkeiten.</p>
+ <div type="subchapter">
+ <head>3.1 Metaheuristik</head>
+ <p>Auch der Algorithmus bildet die
+ eingangs eingeführte inhaltliche Zweiteilung ab: Zum einen die Identifizierung eines
+ Ortes, zum anderen die Bestimmung der historischen administrativen Zugehörigkeit zu
+ einem manuell definierten Zeitpunkt (im Folgenden ›Bezugszeit‹ genannt). Die
+ Identifizierung wird zudem in zwei Unterabschnitte getrennt: Im ersten Teil werden
+ zunächst alle Ortsangaben des Kontextes gesammelt und bewertet.<note type="footnote"> Die Metaheuristik beschränkt sich
+ bei der Hinzuziehung des Kontexts zur Identifizierung auf weitere
+ Ortsangaben. Eine Erläuterung für diese Auswahl ist in Abschnitt 3.4 zu
+ finden. Quellenspezifisch muss der Kontext jeweils definiert
+ werden.</note> Als Erstes werden dabei die Ortsangaben grundlegend
+ bereinigt. Es wird je Ortsangabe geprüft, wie viele Übereinstimmungen mit den
+ Bezeichnungen im Mini-GOV vorliegen. Folgend werden all die Orte, die genau <hi rend="italic">eine</hi> exakte Ãœbereinstimmung aufweisen,
+ identifiziert und in die Kontextdaten mit aufgenommen (siehe <ref type="graphic" target="#urbanonyme_2020_005">Abbildung 5</ref>). Neben den Bezeichnungen und der
+ GOV-ID werden zu den Kontextdaten auch die geographischen Koordinaten
+ gespeichert.</p>
+ <figure>
+ <graphic xml:id="urbanonyme_2020_005" url="Medien/urbanonyme_2020_005.png">
+ <desc>
+ <ref target="#abb5">Abb. 5</ref>: Ermittlung und Bewertung von Kontextdaten, eigene Darstellung als Nassi-Shneiderman-Diagramm. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_005"/>
+ </desc>
+ </graphic>
+ </figure>
+ <p>Mit Hilfe der nun ermittelten
+ Kontextdaten können im zweiten Teil weitere Ortsangaben identifiziert werden (siehe
+ <ref type="graphic" target="#urbanonyme_2020_006">Abbildung 6</ref>): Bei mehreren
+ Übereinstimmungen mit dem Mini-GOV wird geprüft, ob für die zu überprüfende
+ Ortsangabe Kontextdaten zur Verfügung stehen.<note type="footnote"> Es kann sein, dass der Kontext so einen geringen
+ Umfang hat, dass die vorhergehende Ermittlung der Kontextdaten kein Ergebnis
+ brachte. Das ist hier konkret der Fall, wenn keine weiteren Ortsangaben
+ vorliegen.</note> Falls ja, so werden für die verschiedenen
+ Möglichkeiten jeweils die Koordinaten ermittelt und mit den Koordinaten der
+ Kontextdaten verglichen. Der Ort, der nach diesem Vergleich die geringste Distanz
+ aufweist, wird ausgewählt. Sind keine Kontextdaten vorhanden wird über eine
+ Zuordnung auf Basis des Typs der möglichen Orte entschieden.</p>
+ <p>Liegt nach dem eingänglichen Vergleich
+ mit dem Mini-GOV keine genaue Ãœbereinstimmung vor, so findet eine
+ Ähnlichkeitsüberprüfung zwischen der Ortsbezeichnung und den Einträgen im Mini-GOV
+ statt. So können Fehler korrigiert werden, die durch die eingängliche Bereinigung
+ nicht erkannt wurden. Besteht dennoch keine Ähnlichkeit mit einem Objekt aus dem
+ Mini-GOV, bleibt der Ort unidentifiziert. Bei einem oder mehreren Treffern wird wie
+ oben beschrieben verfahren.</p>
+ <figure>
+ <graphic xml:id="urbanonyme_2020_006" url="Medien/urbanonyme_2020_006.png">
+ <desc>
+ <ref target="#abb6">Abb. 6</ref>: Ortsidentifizierung, eigene Darstellung als Nassi-Shneiderman-Diagramm. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_006"/>
+ </desc>
+ </graphic>
+ </figure>
+ <p>Der zweite Teil, die Clusterung,
+ beginnt damit, dass für das zu untersuchende Objekt geprüft wird, ob eine Zuordnung
+ zu einer historisch-administrativen Gliederungseinheit bereits früher erfolgt ist
+ (siehe <ref type="graphic" target="#urbanonyme_2020_007">Abbildung 7</ref>). Das dient der Vermeidung
+ doppelter Programmdurchläufe und somit der Laufzeitverkürzung. Wurde das Objekt noch
+ keiner übergeordneten Einheit zugeordnet, so wird diese in der Baumstruktur der
+ übergeordneten Objekte gesucht. Das erfolgt, indem in maximal zehn Iterationen
+ jeweils ein übergeordnetes Objekt ausgewählt und neu untersucht wird. Hierzu wird
+ jeweils geprüft, ob das Objekt Teil einer definierten Menge ist. Diese Menge stellt
+ die historisch-administrative Zielgliederung (im Folgenden ›Provinz‹) zur Bezugszeit
+ dar. Entspricht das Objekt einem Element der Zielmenge, so wird dem ursprünglichen
+ Objekt diese Provinz zuordnet. Ist das nicht der Fall, so werden die Informationen
+ aus dem GOV-Webservice für das entsprechende Objekt ausgelesen. Dieses Objekt kann
+ nun wiederum für sich übergeordnete Objekte aufweisen, von denen eines für die
+ nächste Iteration auszuwählen ist. Das geschieht, indem jedes übergeordnete Objekt
+ dahingehend geprüft wird, ob die Bezugszeit in den Zeitraum der Zugehörigkeit des
+ untergeordneten zum übergeordneten Objekt fällt. Ist das der Fall, wird das
+ übergeordnete Objekt einer Liste A (höhere Priorität) hinzugefügt. Um beim obigen
+ Beispiel zu bleiben, könnte etwa ›Mark Brandenburg‹ als übergeordnetes Objekt für
+ ›Berlin‹ ausgewählt werden, wenn die Bezugszeit beispielsweise ›1301–1400‹ beträgt.
+ Liegt die Bezugszeit hingegen nicht in der Zeitspanne der Zugehörigkeit zum
+ übergeordneten Objekt, so wird das Objekt einer Liste B (niedrigere Priorität)
+ zugewiesen.<note type="footnote">
+ Liste A und B dienen der Priorisierung weiterer Schritte. Falls die Liste A
+ kein Element enthält, ist kein übergeordnetes Objekt zeitlich exakt passend.
+ Das kann u. a. daran liegen, dass das GOV nicht vollständig gepflegt ist
+ oder aber ein Objekt erst nach der Bezugszeit entstanden ist und deswegen
+ keine Zugehörigkeit zur Bezugszeit bestehen kann. Nur im Falle einer leeren
+ Liste A wird mit der Liste B weiter verfahren.</note> Enthält die
+ entsprechende Liste ein Element, so wird dieses Objekt ausgewählt und mit ihm die
+ neue Iteration begonnen. Enthält die Liste jedoch mehrere Objekte, dann findet ein
+ Vergleich dieser statt. Das ist überwiegend der Fall, wenn die Liste B Verwendung
+ findet. Letztlich wird das Objekt ausgewählt, das zeitlich der Bezugszeit am
+ nächsten ist.</p>
+ <figure>
+ <graphic xml:id="urbanonyme_2020_007" url="Medien/urbanonyme_2020_007.png">
+ <desc>
+ <ref target="#abb7">Abb. 7</ref>: Analyse der provinziellen Zuordnung, eigene Darstellung als Nassi-Shneiderman-Diagramm. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_007"/>
+ </desc>
+ </graphic>
+ </figure>
+ </div>
+ <div type="subchapter">
+ <head>3.2 Datenbereinigung</head>
+ <p>Da es denkbar ist, dass
+ Ortsbezeichnungen systematische Fehler enthalten, ist eine grundsätzliche
+ Bereinigung der Daten angebracht.<note type="footnote"> Je nach Ermittlung der Bezeichnungen sind dabei andere
+ Fehler denkbar. So wird eine automatisierte Texterkennung andere Fehler
+ machen als ein Mensch.</note> Der Algorithmus sollte auf die jeweils
+ auftretenden systematischen Fehler der Quelle spezifisch angepasst werden. Die
+ Veränderung der Ortsbezeichnungen ist dabei nicht unkritisch, da mit dieser eine
+ Interpretation der Daten einhergeht. Auf große Datenmengen angewendet kann es bei
+ verallgemeinerten Korrekturregeln zu vermehrten Fehlinterpretationen kommen (FP). An
+ dieser Stelle werden darum nur allgemeine Fehler abgedeckt (zum Beispiel die
+ Entfernung von Sonderzeichen oder sonstiger unerwünschter Bestandteile). Spezifische
+ Regeln können vom Anwender jeweils ergänzt werden.</p>
+ </div>
+ <div type="subchapter">
+ <head>3.3 Suche</head>
+ <p>Grundlage der Suche eines passenden
+ Ortes sind die Angaben über Namen von Orten im Mini-GOV – und der (teilweisen)
+ Ãœbereinstimmungen mit der gegebenen Ortsbezeichnung aus den Quellen. Das Mini-GOV
+ liegt als CSV-Datei für jeden heute existierenden
+ Staat vor. Aus diesem Grund müssen (neben dem Deutschland-Mini-GOV) weitere Länder,
+ in denen es vormals deutschsprachige Gebiete gab, integriert werden. Die einzelnen
+ Mini-GOVs werden zu einem gemeinsamen zusammengeführt. Dadurch ergibt sich eine
+ Liste mit mehreren Hunderttausend Orten. Zur Reduzierung der Suchdauer des
+ Algorithmus ist es hier wichtig, keine lineare Suche zu verwenden, sondern das
+ Mini-GOV vorher zu sortieren.<note type="footnote"> Beispielsweise bei einer GOV-Liste von 100.000 Orten
+ und 10.000 zu lokalisierenden Urbanonymen wären bei einer einfachen Suche
+ eine Milliarde einzelne Vergleiche durchzuführen.</note> Die Sortierung
+ ermöglicht den Einsatz einer binären Suche.<note type="footnote"> Diese wird so ausgeführt, dass zunächst der
+ mittlere Eintrag der sortierten Instanz des Mini-GOVs identifiziert wird.
+ Liegt die zu suchende Bezeichnung in alphabetischer Reihenfolge vor dem Ort,
+ der in der Mitte steht, wird in einem nächsten Durchlauf die Mitte der
+ vorderen alphabetischen Hälfte analysiert. Das wird so lange wiederholt, bis
+ die nächste Mitte nur noch 10 Positionen von der vorherigen entfernt ist. Da
+ es in einer alphabetischen Reihenfolge in einer Liste mehrere
+ aufeinanderfolgende Treffer geben kann, ist eine vollständige Ausführung der
+ binären Suche nicht angebracht. Diese würde nur ein Element zum Resultat
+ haben. Aus diesem Grund werden die 30 Positionen vor und 30 Positionen nach
+ der letzten ermittelten Mitte zusätzlich linear durchsucht. Das liegt darin
+ begründet, dass kein einzelner Ortsname mehr als 30 Mal im GOV
+ vorkommt.</note> Die Suche kann drei Ergebnisse hervorbringen:</p>
+ <list type="unordered">
+ <item>Kein Treffer: Es gibt keinen Wert im definierten Bereich des Mini-GOVs, der
+ genau der bereinigten Ortsbezeichnung entspricht.</item>
+ <item>Genau ein Treffer: Es gibt nur einen Wert im definierten Bereich des
+ Mini-GOVs, der genau der bereinigten Ortsbezeichnung entspricht.</item>
+ <item>Viele Treffer: Es gibt mehr als einen Wert im definierten Bereich des
+ Mini-GOVs, der genau der bereinigten Ortsbezeichnung entspricht.</item>
+ </list>
+ <p>Bei genau einem Treffer wird eben
+ dieser ausgewählt. In den anderen beiden Fällen ist eine weitere Analyse notwendig.
+ Beim Ausbleiben eines Treffers werden ähnliche Zeichenketten gesucht, da u. a.
+ Tippfehler in den Ortsbezeichnungen eine genaue Ãœbereinstimmung verhindern. Im Fall
+ mehrerer Treffer wird der Kontext der Ortsangabe zur weiteren Identifikation
+ herangezogen (siehe <ref type="intern" target="#hd10">Abschnitt 3.4</ref>).</p>
+ <p>Wird keine genaue Ãœbereinstimmung
+ zwischen Ortsbezeichnung und dem Namen eines Ortes im Mini-GOV gefunden, kann eine
+ teilweise Ãœbereinstimmung bei der Identifizierung helfen. Eine Berechnung zwischen
+ der Ähnlichkeit aller Namen im GOV und der zuzuordnenden Ortsbezeichnung ist vor dem
+ Hintergrund der Rechenkapazität nicht erstrebenswert. Aus diesem Grund werden
+ lediglich die Orte verglichen, die zuvor schon eingegrenzt wurden.<note type="footnote"> Das führt dazu, dass Fehler bei
+ anfänglichen Buchstaben nicht erkannt werden. Die Vorteile durch die
+ schnellere Suche scheinen jedoch für die praktische Durchführung wichtiger
+ zu sein.</note> Zum Vergleich von Strings existieren, wie in <ref type="intern" target="#hd4">Abschnitt 2.2</ref> erörtert, verschiedene
+ Distanzmaße.<note type="footnote">
+ Zandhuis et al. empfehlen zwar initial die Levenshtein-Distanz, bei mehreren
+ Treffern sollte jedoch ein Vergleich der geographischen Entfernung
+ vorgenommen werden. <ref
+ type="bibliography" target="#zandhuis_toponyms_2015">Zandhuis et al. 2015</ref>, S. 37.</note> Die Verwendung
+ unterschiedlicher Distanzmaße wird im <ref type="intern" target="#hd13">Abschnitt 5.
+ Validierung</ref> diskutiert.</p>
+ </div>
+ <div type="subchapter">
+ <head>3.4 Kontextdaten</head>
+ <p>Ansatzpunkte zur Ermittlung der
+ Kontextdaten können sich aus der Quelle der zu lokalisierenden Ortsangabe ergeben.
+ Als Kontext für eine Bezeichnung in einem Buch kann so unter Umständen das ganze
+ Buch dienen. Wie in <ref type="intern" target="#hd3">Abschnitt 2.1</ref> gezeigt, gibt es
+ verschiedene Informationen im Kontext von Ortsbezeichnungen (insbesondere andere
+ Ortsbezeichnungen, Vor- und Nachnamen, Zeitangaben). Im Weiteren werden
+ ausschließlich die anderen Ortsangaben als Kontextangaben genutzt. Für eine Einbindung von Familiennamen könnte zum Beispiel auf den Deutschen Familiennamenatlas zurückgegriffen werden.<note type="footnote"><ref type="bibliography" target="#adwul_familienatlas">Akademie der Wissenschaften und Literatur Mainz / Albert-Ludwigs-Universität Freiburg (Hg.) 2009–2018</ref>.</note> Bei der Einbindung von Vornamen ist zu beachten, dass die geographische Zuordnung mit zunehmender Zeit im Untersuchungszeitraum ab dem 17. Jahrhundert (vor allem aber in der jüngeren Zeit ab dem 20. Jahrhundert) unschärfer wird.<note type="footnote"> Die
+ Personennamensgebung passiert heute in Deutschland weniger formalisiert als noch vor
+ 100 Jahren, sondern bietet mehr individuelle Freiheiten (u. a. eine deutlich
+ größere Variation der Vornamen).</note> Eine fehlende Übersicht zur
+ Veränderung der Ortsnamen im Zeitverlauf führt dazu, dass auch der temporale Aspekt
+ nicht weiter herangezogen wird. Zudem betrifft die Veränderung der Bezeichnung
+ ab dem 17. Jahrhundert nur einen kleinen Teil der Orte. Dagegen sind weitere
+ Ortsangaben als Kontext besonders geeignet, vor allem wenn eine dichte Nennung von
+ Orten erfolgt. Bei einer Ortsangabe in einem Buch, in dem der nächste Ort erst 200
+ Seiten später genannt wird, ist der Kontext hingegen zur Identifizierung
+ voraussichtlich nicht geeignet. Sind in einer Quelle auf 20 Seiten aber 200
+ Ortsangaben, erscheint es wahrscheinlicher, dass diese in einer inhaltlichen
+ Beziehung zueinander stehend genannt werden.<note type="footnote"> Auch diese Aussage ist nicht allgemeingültig: In
+ einer alphabetisch sortierten Ortsliste ist das nicht der Fall.</note>
+ Vor der Anwendung dieses Algorithmus sollten eine Quelle und ihr Kontext dahingehend
+ begutachtet werden.</p>
+ <p>Eine Eigenschaft dieser Vorgehensweise
+ ist, dass Ortsangaben, sollen sie als Kontext zur Identifizierung anderer
+ Ortsangaben genutzt werden, selbst zunächst einmal identifiziert werden müssen. Aus
+ diesem Grund werden alle Ortsangaben zunächst auf Übereinstimmung mit dem Mini-GOV
+ geprüft. Die Ortsangaben, bei denen eine eindeutige Zuordnung zu einem Eintrag im
+ Mini-GOV vorgenommen werden kann, bilden die Kontextdaten. Hier wird deutlich, dass
+ nur ein Teil der Ortsangaben in die Kontextdaten eingeht.</p>
+ <p>Um anhand der Kontextdaten nun eine
+ Auswahl zwischen verschiedenen Orten zu treffen, ist die geographische Nähe das
+ wesentliche Kriterium. Den Grundgedanken, dass die <quote>geographical unit that has the smallest geographic distance to the place of
+ origin</quote> für die Zuordnung von Ortsangaben genutzt werden kann, hatten
+ bereits Zandhuis et al.<note type="footnote"> <ref type="bibliography" target="#zandhuis_toponyms_2015">Zandhuis et al. 2015</ref>, S. 37.</note> Wobei der <quote>place of origin</quote> in dem Fall der Entstehungsort der Quelle
+ der Ortsangabe ist, der (1.) selten vorliegen dürfte und (2.) auch erstmal
+ identifiziert werden müsste. Der Ansatz hingegen, andere Ortsangaben desselben
+ Kontextes zu nutzten, ist neu und basiert auf der Annahme, dass zusammen genannte
+ Orte oftmals auch nah beieinanderliegen. Insbesondere bei genealogischen Quellen
+ trifft diese Annahme zu. So werden oftmals Ehepartner
+ aus einer engeren räumlichen Entfernung gewählt.<note type="footnote"> Vgl. <ref type="bibliography" target="#kocka_familie_1980">Kocka et al. 1980</ref>.</note>
+ Oftmals wurden auch Ehepartner aus dem gleichen Ort gewählt.<note type="footnote"> Vgl. <ref type="bibliography" target="#baehr_bevoelkerungsgeographie_1992">Bähr et al. 1992</ref>.</note> Ein
+ hoher Anteil der Bevölkerung war lange nur sehr eingeschränkt mobil. Diese Methodik
+ ist also insbesondere geeignet für Urbanonyme, die zusammen mit Personen genannt
+ werden (beispielsweise in prosopografischen Quellen). Weniger geeignet ist sie für
+ Quellen, bei denen die Orte eindeutig in keinem räumlichen Zusammenhang stehen (z.
+ B. eine alphabetische Liste aller Städte).</p>
+ <p>Zu jedem Ort in den Kontextdaten
+ liegen durch das Mini-GOV Koordinaten vor. Das geographische Mittel<note type="footnote"> Es gibt keine
+ allgemeingültige Norm des geographischen Mittels, da neben den Koordinaten
+ beispielsweise die Topographie in die Gewichtung mit einfließen kann. An
+ dieser Stelle wird das arithmetische Mittel jeweils von Längen- und
+ Breitengrad genutzt.</note> dieser Orte stellt dabei eine Position dar,
+ die zu allen anderen Orten durchschnittlich die geringste Distanz hat. In dieser
+ Vorgehensweise wird ein weiterer Nachteil ersichtlich: Die Quelle kann Orte
+ enthalten, die geografisch sehr weit voneinander entfernt sind. Wenn diese sich
+ nicht gleichflächig über den Raum verteilen (wovon auszugehen ist), können sich
+ verschiedene Räume mit einer großen Dichte an Datenpunkten ausbilden.<note type="footnote"> Eine alternative
+ Idee ist es aus diesem Grund, nicht alle Orte in die Kontextdaten einfließen
+ zu lassen, sondern vormals nochmal zu selektieren. Bei genealogischen Daten
+ könnten z. B. nur die Orte der Personen, die eine nahe verwandtschaftliche
+ Verknüpfung aufweisen, einbezogen werden. Die Verwandtschaftsbeziehungen
+ stellen weitere Kontextdaten dar. Die wenigsten historischen Quellen
+ verfügen jedoch speziell über diese Kontextdaten. Aus diesem Grund findet
+ dieser Aspekt keine Anwendung.</note> Die geographische Mitte würde in
+ keinem dieser Ballungsgebiete liegen. Hierbei schafft die Bildung dezentraler
+ (Orts-)Cluster<note type="footnote"> Diese
+ Bildung von Cluster aus den Kontextdaten ist nicht mit der (späteren)
+ Clusterung der identifizierten Orte entsprechen ihrer regionalen
+ Zusammengehörigkeit identisch. Vielmehr dürfen diese nicht verwechselt
+ werden. In beiden Fällen wird geclustert, weshalb der Begriff derselbe ist.
+ Zur Unterscheidung ist ein genauer Blick auf den Zusammenhang zu werfen, in
+ dem der Begriff verwendet wird. Zur besseren Nachvollziehbarkeit wird diese Art von Clusterung von (Orts-)Clusterung genannt.</note> Abhilfe. Die Validierung wird
+ zeigen, welche praktischen Auswirkungen diese Art der (Orts-)Clusterung mit sich
+ bringt.</p>
+ <p>Für den Fall, dass keine Kontextdaten
+ vorhanden sind, jedoch trotzdem eine Auswahl zwischen verschiedenen Orten
+ stattfinden soll, ist eine alternative Entscheidungsfindung zu definieren. So kann –
+ unter Hinzuziehung weiterer Heuristiken – auf die Wahrscheinlichkeit für die
+ Zugehörigkeit eines Urbanonyms zu einem bestimmten Ort geschlossen werden. Wenn z.
+ B. gleichnamig eine Stadt und ein kleiner Weiler mit demselben Ortsnamen existieren,
+ dann ist es wahrscheinlicher, dass die Stadt gemeint ist. Dahinter wiederum verbirgt
+ sich die Annahme, dass mehr Menschen in einer Stadt als in einer kleinen Ansammlung
+ von Häusern gelebt haben. Diese Unterscheidung wird durch die Objekttypen im
+ Mini-GOV ermöglicht. Dazu wird die folgende Reihenfolge definiert. Die Reihenfolge muss nicht in jedem Fall richtig sein, sondern ist hier vor allem durch die individuelle Einschätzung des Autors bedingt und kann demnach verändert werden. </p>
+ <list type="ordered">
+ <item>Kreisfreie Stadt</item>
+ <item>Stadt</item>
+ <item>Dorf</item>
+ <item>Pfarrdorf</item>
+ <item>Ort</item>
+ <item>Ortsteil</item>
+ <item>Ortschaft</item>
+ <item>Wohnplatz</item>
+ <item>Weiler </item>
+ </list>
+ <p>Sollten zwei Orte gleichen Objekttyps
+ übrigbleiben, ist eine Identifizierung fehlgeschlagen.</p>
+ </div>
+ <div type="subchapter">
+ <head>3.5 Clusterung zur historischen administrativen Zugehörigkeit</head>
+ <p>Sind die Orte (im Folgenden ›Objekte‹)
+ identifiziert, so stehen zu ihnen verschiedene Metadaten aus dem Mini-GOV zur
+ Verfügung. Angaben zur historischen administrativen Zugehörigkeit sind dort
+ allerdings nicht zu finden. Über den Webservice des GOV können diese Angaben jedoch
+ ermittelt werden, da dort die historische Zugehörigkeit eingesehen werden kann. Die
+ hierarchische Anordnung von unter- und übergeordneten Objekten ergibt eine
+ Baumstruktur. Jedes Objekt hat Informationen über seine übergeordneten Objekte. In
+ der Folge liegt die Baumstruktur nicht zu Beginn vor, sondern wird mit der Abfrage
+ jedes übergeordneten Objektes implizit weiter aufgebaut. Durch die Verknüpfung der
+ Zugehörigkeiten ergibt sich eine Baumstruktur (Beispiel in <ref type="graphic" target="#urbanonyme_2020_008">Abbildung 8</ref>). Um eine administrative
+ Zugehörigkeit zu ermitteln, ist es Ziel, den richtigen Pfad in der Baumstruktur zu
+ finden. Das geht nur, wenn zuvor mögliche Ziele (Cluster, Provinzen) definiert
+ werden. Die Zielmenge ist dabei zeitabhängig: Je nach gewünschter Zeit kann die
+ Clusterung anders ausgestaltet sein. Dazu muss die Zielmenge für verschiedene
+ Bezugszeiten definiert werden. Fertig et al. strukturieren das deutschsprachige
+ Gebiet in 39 Einheiten, die den Zeitraum von 1816 bis 1871 abdecken.<note type="footnote"> Vgl. <ref type="bibliography" target="#fertig_zeitalter_2018">Fertig et al.
+ 2018</ref>.</note> Für einen möglichen Bezug auf die heute existierende
+ Gliederung werden die sechzehn Bundesländer Deutschlands genutzt.<note type="footnote"> Beispiel: Bei einem Interesse an
+ der Zuordnung Dresdens wäre im Jahr 2000 der Freistaat Sachsen korrekt
+ (GOV-Objekt ›object_218149‹), 1850 aber beispielsweise das Königreich
+ Sachsen (GOV-Objekt ›object_218149‹).</note> Allerdings könnte auch eine
+ Gliederung heutiger Daten in den Grenzen von 1850 – oder andersherum, die Einteilung
+ historischer Daten in den heutigen Grenzen – interessant sein. Diese wird durch eine
+ Variation der Bezugszeit ermöglicht. Eine Zuordnung möglicher Provinzen mit
+ GOV-Objekten ist folgend aufgeführt (siehe <ref type="intern" target="#tab02">Tabelle
+ 2</ref>). Weitere Regionen – oder eine detailliertere Skalierung der möglichen
+ Cluster (u. a. Kreise, Regierungsbezirke) – können bei Bedarf implementiert
+ werden.</p>
+ <figure>
+ <graphic xml:id="urbanonyme_2020_008" url="Medien/urbanonyme_2020_008.png">
+ <desc>
+ <ref target="#abb8">Abb. 8</ref>: GOV-Struktur der Stadt <ref target="http://gov.genealogy.net/item/show/object_113700">Wiedenbrück</ref>, Stand: 30. Januar 2021. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_008"/>
+ </desc>
+ </graphic>
+ </figure>
+ <table>
+ <row>
+ <cell>Provinz<note type="footnote"> Die mit A angeführten Provinzen sind Preußen zugehörig, dem mit
+ dem B stellen weitere Territorien dar.</note>
+ </cell>
+ <cell>GOV-Identikator</cell>
+ <cell>Bemerkung</cell>
+ </row>
+ <row>
+ <cell>ab hier Bezugszeit
+ <= 1871</cell>
+ </row>
+ <row>
+ <cell>A 01 Provinz Holstein</cell>
+ <cell>object_190122</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>A 02 Provinz Lauenburg</cell>
+ <cell>adm_131053</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>A 03 Provinz Brandenburg (ohne
+ Berlin)</cell>
+ <cell>object_1081716</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>A 04 Provinz
+ Hessen-Nassau</cell>
+ <cell>object_190330</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>A 05 Provinz
+ Hohenzollern</cell>
+ <cell>object_268785</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>A 05 Provinz
+ Hohenzollern</cell>
+ <cell>object_284443</cell>
+ <cell>Hohenzollern-Sigmaringen 1850
+ nach Hohenzollerschen Landen</cell>
+ </row>
+ <row>
+ <cell>A 06 Provinz Ostpreußen</cell>
+ <cell>adm_368500</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>A 07 Provinz Pommern</cell>
+ <cell>adm_368480</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>A 08 Provinz Posen</cell>
+ <cell>object_211667</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>A 09 Provinz Sachsen</cell>
+ <cell>object_279654</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>A 10 Provinz Schlesien</cell>
+ <cell>adm_368470</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>A 11 Provinz Westfalen</cell>
+ <cell>object_190325</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>A 12 Provinz Westpreußen</cell>
+ <cell>object_213750</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>A 13 Rheinprovinz</cell>
+ <cell>object_1047283</cell>
+ <cell>Provinz Jülich-Kleve-Berg bis
+ 1822</cell>
+ </row>
+ <row>
+ <cell>A 13 Rheinprovinz</cell>
+ <cell>object_405464</cell>
+ <cell>Provinz Großherzogtum
+ Niederrhein bis 1822</cell>
+ </row>
+ <row>
+ <cell>A 13 Rheinprovinz</cell>
+ <cell>object_190337</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>A 14 Provinz Berlin</cell>
+ <cell>BERLINJO62PM</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 01 Amt Bergedorf</cell>
+ <cell>object_257607</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 02 Hansestadt Bremen</cell>
+ <cell>adm_369040</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 03 Stadt Hamburg</cell>
+ <cell>adm_369020</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 04 Stadt Lübeck</cell>
+ <cell>LUBECKJO53IU</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 05 Stadt Frankfurt am
+ Main</cell>
+ <cell>adm_136412</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 06 Fürstentum
+ Lippe-Detmold</cell>
+ <cell>object_217406</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 07 Fürstentum
+ Schaumburg-Lippe</cell>
+ <cell>object_217818</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 08 Fürstentum
+ Waldeck-Pyrmont</cell>
+ <cell>object_218152</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 09 Großherzogtum
+ Oldenburg</cell>
+ <cell>object_352387</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 10 Großherzogtum Baden</cell>
+ <cell>object_217952</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 11 Hessen</cell>
+ <cell>object_218147</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 12 Großherzogtum
+ Mecklenburg-Schwerin</cell>
+ <cell>object_217750</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 13 Großherzogtum
+ Mecklenburg-Strelitz (einschließlich des Fürstentums Ratzeburg)</cell>
+ <cell>object_217749</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 14 Herzogtum Anhalt</cell>
+ <cell>object_190873</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 15 Herzogtum
+ Braunschweig</cell>
+ <cell>object_217954</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 16 Herzogtum Nassau</cell>
+ <cell>object_218153</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 17 Herzogtum Schleswig</cell>
+ <cell>object_190098</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 18 Königreich
+ Württemberg</cell>
+ <cell>object_190729</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 19 Königreich Bayern</cell>
+ <cell>object_217953</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 20 Königreich Hannover</cell>
+ <cell>object_190327</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 21 Königreich Sachsen</cell>
+ <cell>object_218149</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 22 Kurfürstentum
+ Hessen</cell>
+ <cell>object_275299</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 23 Landgrafschaft
+ Hessen-Homburg</cell>
+ <cell>object_284442</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>B 24 Thüringische
+ Staaten</cell>
+ <cell>object_218143</cell>
+ <cell>Sachsen-Weimar-Eisenach</cell>
+ </row>
+ <row>
+ <cell>B 24 Thüringische
+ Staaten</cell>
+ <cell>object_284441</cell>
+ <cell>Reuß Jüngere Linie</cell>
+ </row>
+ <row>
+ <cell>B 24 Thüringische
+ Staaten</cell>
+ <cell>object_218134</cell>
+ <cell>Reuß Ältere Linie</cell>
+ </row>
+ <row>
+ <cell>B 24 Thüringische
+ Staaten</cell>
+ <cell>object_218137</cell>
+ <cell>Sachsen-Altenburg</cell>
+ </row>
+ <row>
+ <cell>B 24 Thüringische
+ Staaten</cell>
+ <cell>object_218138</cell>
+ <cell>Sachsen-Coburg-Gotha</cell>
+ </row>
+ <row>
+ <cell>B 24 Thüringische
+ Staaten</cell>
+ <cell>object_265487</cell>
+ <cell>Sachsen Gotha</cell>
+ </row>
+ <row>
+ <cell>B 24 Thüringische
+ Staaten</cell>
+ <cell>object_218142</cell>
+ <cell>Sachsen-Meiningen</cell>
+ </row>
+ <row>
+ <cell>B 24 Thüringische
+ Staaten</cell>
+ <cell>object_218150</cell>
+ <cell>Schwarzburg-Rudolstadt</cell>
+ </row>
+ <row>
+ <cell>B 24 Thüringische
+ Staaten</cell>
+ <cell>object_218151</cell>
+ <cell>Schwarzburg-Sondershausen</cell>
+ </row>
+ <row>
+ <cell>B 24 Thüringische
+ Staaten</cell>
+ <cell>object_218141</cell>
+ <cell>Sachsen-Hildburghausen</cell>
+ </row>
+ <row>
+ <cell>ab hier Bezugszeit
+ >= 1990</cell>
+ </row>
+ <row>
+ <cell>Land Baden-Württemberg</cell>
+ <cell>adm_369080</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>Freistaat Bayern</cell>
+ <cell>adm_369090</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>Land Berlin<note type="footnote"> Berlin heute stellt das
+ gleiche GOV-Objekt dar wie bei der historischen Klassifizierung.
+ Insofern wir hier die Bezeichnung <hi rend="italic">A 14
+ Provinz Berlin</hi> und nicht <hi rend="italic">Land
+ Berlin</hi> ausgegeben.</note>
+ </cell>
+ <cell>BERLINJO62PM</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>Land Brandenburg</cell>
+ <cell>adm_369120</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>Freie Hansestadt Bremen</cell>
+ <cell>adm_369040</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>Freie und Hansestadt
+ Hamburg</cell>
+ <cell>object_1259992</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>Land Hessen</cell>
+ <cell>adm_369060</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>Land
+ Mecklenburg-Vorpommern</cell>
+ <cell>adm_369130</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>Land Niedersachsen</cell>
+ <cell>adm_369030</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>Land Nordrhein-Westfalen</cell>
+ <cell>adm_369050</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>Land Rheinland-Pfalz</cell>
+ <cell>adm_369070</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>Saarland</cell>
+ <cell>adm_369100</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>Freistaat Sachsen<note type="footnote"> Hier besteht
+ die gleiche Situation wie bei Berlin (siehe vorherige
+ Fußnote).</note>
+ </cell>
+ <cell>object_218149</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>Land Sachsen-Anhalt</cell>
+ <cell>adm_369150</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>Land Schleswig-Holstein</cell>
+ <cell>adm_369010</cell>
+ <cell/>
+ </row>
+ <row>
+ <cell>Freistaat Thüringen</cell>
+ <cell>adm_369160</cell>
+ <cell/>
+ </row>
+
+ <trailer xml:id="tab02">
+ <ref type="intern" target="#tab2">Tab. 2</ref>: Zuordnung von Provinzen zum GOV. [Goldberg 2022]<ref type="graphic"
+ target="#urbanonyme_2020_t2"/>
+ </trailer> </table>
+
+ <p>Zur Suche in der Baumstruktur über-
+ und untergeordneter Objekte wird im Folgenden ein informiertes Vorgehen genutzt.
+ Dazu wird jeweils geprüft, ob das derzeitige Objekt Teil der Zielmenge ist. Ist es
+ das nicht, werden die übergeordneten Objekte durchsucht. Hierbei wird überprüft, ob
+ es ein Objekt gibt, welches in den Zeitraum der Bezugszeit fällt. Kann auf die Weise
+ kein übergeordnetes Objekt identifiziert werden, wird dasjenige ausgewählt, dessen
+ Grenzen der zeitlichen Zugehörigkeit am nächsten an der Bezugszeit liegen (z. B. die
+ Bezugszeit 1820 und die zeitlichen Grenzen des nächsten Objektes von
+ 1822-1838).<note type="footnote"> Die
+ Nähe der Grenzen zur Bezugszeit ist auch in dem seltenen Fall das Kriterium,
+ in dem mehrere übergeordnete Objekte in der Bezugszeit liegen.</note>
+ Sind ausschließlich übergeordnete Objekte ohne Zeitangaben vorhanden, weisen sie den
+ gleichen Abstand zur Bezugszeit auf. In dem Fall wird die nächste Iteration mit dem
+ erstgenannten Objekt der GOV-Abfrage durchgeführt. Solche Objekte, die einen
+ kirchlichen oder juristischen Typ<note type="footnote"> Objekte können im Zeitverlauf verschiedenen Typen
+ unterliegen, dieser Umstand wird nicht weiter betrachtet, weil sich die
+ Objektkategorie nicht ändert. Ein Dorf kann beispielsweise zur Stadt werden,
+ eine Kirche aber nicht zur Stadt.</note> aufweisen oder nur im
+ nicht-deutschsprachigen Raum vorkommen, werden ausgeschlossen.<note type="footnote"> Beispielsweise bei dem Objekt
+ ›NEUTE1JO44XB‹ gibt es zwei übergeordnete Objekte ohne zeitliche Angaben.
+ Hier erfolgt jedoch eine konkrete Zuordnung zu dem Objekt, das keinen
+ kirchlichen Typ aufweist.</note> Wird ein übergeordnetes Objekt
+ identifiziert, das Teil der Zielmenge ist, ist die Suche der historischen
+ administrativen Gebietskörperschaft gelungen – der Ort wird der Provinz
+ zugeordnet.<note type="footnote">
+ Eine Alternative dazu wäre eine klassische Tiefen- oder Breitensuche.
+ Hierbei würden alle Zweige des Baumes analysiert, bis ein Objekt der
+ Zielmenge gefunden wird. Das ist vor dem Hintergrund von Laufzeitaspekten
+ ungünstig, da dazu sehr oft auf das nur online verfügbare GOV zugegriffen
+ werden müsste und die Internet-Schnittstelle zu einer Verlängerung der
+ Durchlaufzeit führte.</note>
+ </p>
+ <p>Nach der Ermittlung der Zugehörigkeit
+ zu einer historischen Provinz wird diese gespeichert. Bei einer großen Anzahl von zu
+ identifizierenden Ortsbezeichnungen bietet diese Vorgehensweise den Vorteil, dass
+ doppelt vorkommende Ortsangaben mit denselben Kontextdaten nicht doppelt bearbeitet
+ werden.</p>
+ <p>Dieser Algorithmus findet die
+ entsprechende Provinz nicht, wenn </p>
+ <list type="ordered">
+ <item>durch die GOV-Abfrage keine übergeordneten Objekte ausgegeben werden
+ (Beispielobjekt ›LIEHA2JO62RV‹) oder </item>
+ <item>kein Objekt der Zielmenge in den übergeordneten Objekten auftaucht,<note type="footnote"> Das ist derzeit
+ bei allen Orten der ehemaligen Provinz Holstein der Fall, da diese nicht
+ mit dem entsprechenden Objekt im GOV verknüpft sind. Allerdings kann
+ dieses auch einzelne Orte anderer Provinzen betreffen, z. B. Wesel
+ (›WESSELJO31HQ‹, Stand 18. Juni 2020). Dadurch, dass das GOV stetig
+ erweitert wird, können die fehlenden Verknüpfungen in der Zukunft
+ nachgeholt werden.</note> was </item>
+ <item>auch daran liegen kann, dass der identifizierte Ort im Ausland (also außerhalb
+ der Zielmenge) liegt.</item>
+ </list>
+ </div>
+ </div>
+ <div>
+ <p></p>
+ <p></p>
+ <p></p>
+ <p></p>
+ </div>
+ <div type="chapter">
+ <head>4. Anpassung auf GEDCOM-Dateien</head>
+ <p>Zur Vorbereitung der Validierung wurde der entwickelte Algorithmus in der
+ Programmiersprache Python 3.7 umgesetzt. Der Programmcode ist im <ref target="https://git.hab.de/forschungsdaten/zeitschrift-fuer-digitale-geisteswissenschaften/goldberg-urbanonyme">Online-Repositorium</ref>
+ einsehbar. Er gliedert sich in verschiedene Funktionen, die zunächst einzeln
+ erläutert und dann in ihrem Zusammenhang dargestellt werden. Die Kommentare im
+ Programmcode beschreiben die konkrete Umsetzung des Algorithmus detailliert, sodass
+ hier auf eine tief gehende Erläuterung verzichtet wird. Zum besseren Verständnis des
+ Programms wird hier vielmehr der Aufbau beschrieben. Das Verständnis der Struktur
+ hilft dabei, das Programm anzupassen. Grundlegend ist das Programm in die drei
+ Bestandteile aufgeteilt, die auch schon zur Teilung des Algorithmus dienten (siehe
+ <ref type="graphic" target="#urbanonyme_2020_009">Abbildung 9</ref>). Hierzu werden in jedem
+ Schritt eigene CSV-Dateien mit den Zwischenergebnissen erstellt und ausgegeben.</p>
+ <figure>
+ <graphic xml:id="urbanonyme_2020_009" url="Medien/urbanonyme_2020_009.png">
+ <desc>
+ <ref target="#abb9">Abb. 9</ref>: Aufbau des Programms. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_009"/>
+ </desc>
+ </graphic>
+ </figure>
+ <p>Vor der Main-Funktion wird dieser
+ Prozess einmal je GEDCOM-Datei angestoßen (siehe <ref type="graphic" target="#urbanonyme_2020_010">Abbildung 10</ref>, die Pfeile zeigen an, in welcher Systematik die Funktionen
+ aufgerufen werden). Bevor das geschehen kann, werden die zu untersuchenden
+ GEDCOM-Datei vorbereitend so verändert, dass die Dateinamen eine Zahl gefolgt von
+ der Dateinamen-Endung ›.ged‹ beinhaltet (d. h. ›1.ged‹, ›2.ged‹ etc.). Zahlen dürfen
+ nicht doppelt vorkommen, jedoch ausgelassen werden. Eine durchlaufende Nummerierung
+ ist empfohlen. </p>
+ <p>Ãœber die Funktion <code>importMiniGOV()</code> findet ein Import des Mini-GOV statt. Hier runter sind
+ verschiedene Textdateien zu verstehen, die zuvor je (heutigem) Staat vom CompGen
+ bereitgestellt werden.<note type="footnote"> Vgl. <ref type="bibliography" target="#verein_index_2021b">Verein für Computergenealogie e. V. (Hg.)
+ 2021b</ref>.</note> Es werden die Mini-GOV-Dateien zu Deutschland, Polen,
+ Österreich, der Schweiz, Tschechien, Dänemark, Frankreich und den Niederlanden
+ integriert. Deutschsprachige Ortsnamen sind als <hi rend="italic">aktueller Name</hi> oder <hi rend="italic">letzter deutscher
+ Name</hi> gekennzeichnet. Falls es Letzteren gibt, so wird ein zusätzlicher
+ Eintrag kreiert, indem der alte Name den neuen überschreibt.<note type="footnote"> Die Eintragungen der anderen
+ europäischen Staaten, die keinen letzten deutschen Ortsnamen aufweisen, werden
+ bewusst nicht gelöscht, da das Programm unnötig verschlechtert würde und so
+ ein Ansatz gelegt ist, um auch auf internationale Ortsangaben adaptiert zu
+ werden.</note> Ansonsten werden die Mini-GOVs aneinandergesetzt und
+ alphabetisch sortiert. Hintergrund der Sortierung ist die Ermöglichung einer binären
+ Suche darin.</p>
+ <p>Da viele GEDCOM-Dateien einzeln und
+ voneinander unabhängig zu bearbeiten sind, ist eine Parallelisierung des
+ Programmcodes sinnvoll. Die Funktion <code>parallel()</code> wird dazu
+ parallel aufgerufen und bearbeiten. Wesentlich darin ist der nacheinander folgende
+ Aufruf von <code>mainMetadataInspector()</code>,
+ <code>mainPlaceFinder() </code>und <code>mainProvinceFiner()</code>. Die Ergebnisse aus diesen jeweiligen
+ Funktionsaufrufen werden mit der Funktion <code>appendFile()</code> den
+ CSV-Dateien hinzugefügt. Diese Dateien sind zuvor über die Funktion <code>createFile()</code> erstellt worden. Dazu dient unterstützend die
+ Funktion <code>loadData()</code>. Ebenso wurden zuvor die Daten der
+ jeweiligen GEDCOM-Datei über <code>loadGedcomFile()</code> geladen.</p>
+ <figure>
+ <graphic xml:id="urbanonyme_2020_010" url="Medien/urbanonyme_2020_010.png">
+ <desc>
+ <ref target="#abb10">Abb. 10</ref>: Funktionsweise der
 Main. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_010"/>
+ </desc>
+ </graphic>
+ </figure>
+ <p>Für die Inspektion des Kontextes wird
+ eine Liste von Metadaten zu den einzelnen GEDCOM-Dateien geschaffen (siehe <ref type="graphic" target="#urbanonyme_2020_011">Abbildung 11</ref>). Dazu werden in der Funktion <code>prePlaceFinder()</code> die Ortsangaben über den Tag <code>PLAC</code> erkannt und über die Funktion
+ <code>minigovSearch() </code>geprüft, ob sie nur
+ eine Übereinstimmung im Mini-GOV aufweist. Hierzu wird über eine binäre Suche nach
+ der Anzahl an Ãœbereinstimmungen gesucht. Die jeweilige Ortsangabe wird dadurch
+ bereinigt, indem nur der Teil nach einem möglichen ersten Komma entfernt wird. Wenn
+ nur ein Treffer erzielt wurde, so wird der Ort in eine Liste eindeutiger Orte mit
+ aufgenommen – die selektierten Kontextdaten.</p>
+ <p>Nachfolgend wird in der Funktion <code>qualityChecker()</code> zunächst geprüft, ob die untersuchte
+ Datei schon einmal vollständig verarbeitet wurde. In dem Fall wird für jede
+ Ortsangabe zunächst nochmal geprüft, ob sie in der Liste der eindeutigen Werte
+ vorhanden ist. Nicht zu allen eindeutigen Bezeichnungen gibt es jedoch
+ Koordinatenangaben. Einträge, bei denen diese fehlen, finden keine weitere
+ Beachtung. Mit den restlichen wird ein (Orts-)Clusterungsverfahren durchgeführt. Das
+ gröbste mögliche (Orts-)Cluster stellt dabei den Mittelpunkt aus allen selektierten
+ Kontextdaten dar. Sinnvolle Parameter für die Feinheit der (Orts-)Clusterung werden in der
+ Validierung ermittelt. Die Koordinaten der (Orts-)Cluster werden zurückgegeben und ergänzen
+ die Metadaten der Datei. <code>qualityChecker()</code> greift auf
+ verschiedene Funktionen zu: Mithilfe der Funktion <code>gedcomRowParser()</code> werden die Bestandteile einer GEDCOM-Zeile separiert;
+ <code>stringDoublingCounter()</code> dient der Zählung von
+ (Orts-)Clustern.</p>
+ <p>Im Ergebnis bestehen die Metadaten aus
+ der Bezeichnung der Datei, den Durchschnittskoordinaten der selektierten
+ Kontextdaten, der Anzahl eindeutiger Ortsbezeichnungen, der Anzahl daraus gebildeter
+ (Orts-)Cluster sowie den Mittelpunkten jedes einzelnen (Orts-)Clusters. Die durchschnittlichen
+ Koordinaten ergeben sich aus dem arithmetischen Mittel der Längen- und Breitengrade
+ aller so gefundenen Ortsangaben.</p>
+ <figure>
+ <graphic xml:id="urbanonyme_2020_011" url="Medien/urbanonyme_2020_011.png">
+ <desc>
+ <ref target="#abb11">Abb. 11</ref>: Funktionsweise der
 Kontextdatenanalyse. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_011"/>
+ </desc>
+ </graphic>
+ </figure>
+ <p>In der Funktion <code>mainPlaceFinder()</code> werden die Daten durch die Funktion <code>dataCleaner()</code> zunächst einer weitreichenden Bereinigung unterzogen (siehe
+ <ref type="graphic" target="#urbanonyme_2020_012">Abbildung 12</ref>). In der Funktion <code>stringFunc1()</code> wird dazu unter anderem geprüft, ob eine
+ bestimmte Zeichenkette am Anfang steht; diese wird sodann gelöscht, andernfalls wird
+ alles vor dem Teilstring beibehalten. In <code>stringFunc2()</code>
+ fehlt diese alternative Bedingung. Wie im <ref type="intern" target="#hd11">vorherigen
+ Abschnitt</ref> zerteilt die Funktion
+ <code>gedcomRowParser() </code>die einzelnen
+ GEDCOM-Zeilen in ihre Bestandteile.</p>
+ <p>Die konkrete Auswahl eines Orts zu
+ einer gegeben Ortsbezeichnung auf Basis der Kontextdaten findet in der Funktion <code>find()</code> statt, die durch die Funktion <code>placefinder()</code> vorbereitet wird. Hier wird im näheren der in <ref type="graphic" target="#urbanonyme_2020_006">Abbildung 6</ref> gegebene Prozess umgesetzt. Unter
+ anderem findet die kontextsensitive Zuordnung von Ortsbezeichnungen und Orten hier
+ statt. Die Suche nach (Orts-)Clustern im Umkreis der Koordinate ist in die Funktion <code>areaSearch()</code> ausgegliedert. Hier wird auch die
+ typenbasierte Zuordnung realisiert, falls die Umkreissuche fehlschlägt.</p>
+ <p>Als Ergebnis steht eine Tabelle zur
+ Verfügung, die für jede (unbereinigte) Ortsbezeichnung in jeder Quelle eine Zeile
+ mit der GOV-URI, ihren ermittelten Koordinaten, der Information, über welche Art und
+ Weise die Funktion <code>find()</code> die Zuordnung getroffen hat, der
+ bereinigten und unbereinigten Ortsangabe sowie den Dateinamen enthält.</p>
+ <figure>
+ <graphic xml:id="urbanonyme_2020_012" url="Medien/urbanonyme_2020_012.png">
+ <desc>
+ <ref target="#abb12">Abb. 12</ref>: Funktionsweise der
 Ortssuche. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_012"/>
+ </desc>
+ </graphic>
+ </figure>
+ <p>Zuletzt wird die Provinzsuche durch
+ die Funktion <code>mainProvincefinder()</code> realisiert (siehe <ref type="graphic" target="#urbanonyme_2020_013">Abbildung 13</ref>). Zu jedem zuvor identifizierten
+ Objekt wird die Funktion <code>provincefinder()</code> initiiert.
+ Hierin findet die Suche in der übergeordneten Baumstruktur des GOVs statt. Die dazu
+ notwendigen Informationen werden über die Funktion <code>callWebservice()</code> aus dem Internet abgerufen; es ist also eine
+ Internetverbindung vom ausführenden Gerät vonnöten. Es wird angenommen, dass kein
+ Baum mehr als zehn Ebenen besitzt. Deswegen wird in maximal zehn Iterationen immer
+ eines der übergeordneten Objekte ausgewählt und untersucht. Zunächst wird dazu
+ geprüft, ob eines der Objekte bereits Teil der Zielmenge ist.<note type="footnote"> Die Zuordnung von Provinzen zu
+ GOV-Objekten ist in <ref type="intern" target="#tab06">Tabelle 6</ref> definiert. Diese GOV-URIs bilden die Zielmenge
+ für die Clusterung der identifizierten Orte.</note> Wenn das nicht der
+ Fall ist, wird die Zeitspanne der Zugehörigkeit zur Auswahl herangezogen. Zur
+ Berechnung von Beginn- oder Endjahren aus Zeitspannen der Zugehörigkeit zu
+ übergeordneten Objekten im GOV werden die Funktionen <code>beginCalculator()</code> bzw. <code>endCalculator()</code> genutzt.
+ In diesem wird aus der julianischen Angabe der Zeitspanne eine gregorianische
+ Jahresangabe ermittelt. Da die Zeitangaben im GOV oftmals unvollständig sind,
+ existiert ein System, dass mögliche Objekte priorisiert und so die
+ Wahrscheinlichkeit vergrößert, das richtige Objekt auszuwählen. Dabei existieren
+ auszuschließende Objekte (hier: Objekte kirchlichen Typus, ausschließlich
+ Verwaltungsgliederungen anderer Staaten oder gerichtliche Institutionen), die nicht
+ ausgewählt werden sollen. Hieraus folgt das Endergebnis: Eine Tabelle, die die
+ ursprüngliche Bezeichnung, den Namen der Quelldatei, die GOV-URI sowie die
+ Bezeichnung der zugeordneten Provinz enthält.</p>
+ <figure>
+ <graphic xml:id="urbanonyme_2020_013" url="Medien/urbanonyme_2020_013.png">
+ <desc>
+ <ref target="#abb13">Abb. 13</ref>: Funktionsweise der
 Provinzsuche. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_013"/>
+ </desc>
+ </graphic>
+ </figure>
+ </div>
+ <div type="chapter">
+ <head>5. Validierung und Diskussion</head>
+ <p>Zur Validierung des Algorithmus werden
+ GEDCOM-Dateien aus GEDBAS genutzt. Hier können GEDCOM-Dateien von Nutzer*innen ohne
+ grundsätzliche Beschränkung hochgeladen werden. Dabei können die Nutzer*innen beim
+ Hochladen zulassen, dass ihre Datei anderen zum Download frei zur Verfügung steht.
+ Diese downloadbaren Dateien stellen die Datenbasis für die Validierung dar. Dazu
+ wird der bei Goldberg und Moeller beschriebene Scraper genutzt.<note type="footnote"> Vgl. <ref type="bibliography" target="#goldberg_extraktion_2021">Goldberg / Moeller
+ 2021</ref>.</note> Eine Ausführung des Scrapers am 15. April 2020 erbrachte 1.899
+ GEDCOM-Dateien. Diese enthalten 3.371.825 durch den Tag <code>PLAC</code>
+ <note type="footnote">
+ Neben dem Tag <code>PLAC</code> gibt es auch die Tags <code>FORM</code> (wenn er sich auf <code>PLAC</code> bezieht) oder <code>_LOC</code>, ja sogar die
+ direkte Möglichkeit der Angabe von Koordinaten über <code>LATI</code> und <code>LONG</code>. Ebenso existiert der Tag
+ <code>_GOV</code>, mit dem zu einem Ort direkt die GOV-URI
+ zugeordneten werden kann. Diese finden allerdings in GEDBAS eher weniger
+ Verwendung (<code>FORM</code> in Bezug auf <code>PLAC</code>: 2.085 Verwendungen über alle Dateien (diese allerdings in
+ nur 8 verschiedenen Dateien), <code>_LOC</code>: 101.603 (50),
+ <code>LATI</code>: 54.719 (88), <code>LONG</code>: 54.718 (88), <code>_GOV</code>: 5.043 (26)).
+ Das Ergebnis bestätigt die Auffassung von Gellatly, dass diese Art der Geokodierung mehrheitlich nicht genutzt
+ wird, vgl. Gellatly 2015, S. 118. Aufgrund dieser sehr geringen Verwendung
+ wird sich im Weiteren auf den Tag <code>PLAC</code> bezogen. Es
+ ist nachdrücklich erstrebenswert, dass Genealogen diese Felder künftig
+ direkt pflegen.</note> definierte Ortsangaben. Eine Separierung der
+ Verwaltungszugehörigkeit durch ein Komma wird in den GEDCOM-Dateien in den
+ überwiegenden Fällen nicht eingehalten, sodass diese Regelung schwerlich zu
+ Identifizierung genutzt werden kann – und da wo sie eingehalten wird, werden
+ unterschiedliche Verfahren genutzt.<note type="footnote"> In 1.629.274 <code>PLAC</code>-Angaben
+ (48 Prozent) kommen insgesamt 3.933.251 Kommata vor – bei einer konsistenten
+ Verwendung wären es etwa zehn Millionen. Allerdings ist zu erkennen, dass
+ die Kommasetzung in einigen großen (meist englischsprachigen) Dateien stark
+ konzentriert ist: 80 Prozent der Kommata fallen in 2,6 Prozent der Dateien
+ an. Allein 13 Dateien (von 2.899) enthalten die Hälfte aller <code>PLAC</code>-Kommata. Das zeigt deutlich, dass diese
+ Ordnungssystematik bei der Identifizierung von GEDBAS-Urbanonymen keine
+ breite Hilfestellung sein kann.</note>
+ </p>
+ <p>Etwa 12 Prozent dieser
+ Ortsbezeichnungen sind einem Objekt im Mini-GOV direkt zuzuordnen. Sie stellen
+ demnach die Kontextdaten dar. Für weitere 34 Prozent gibt es mehrere, für 54 Prozent
+ keinen Treffer. Diese 12 Prozent bilden die selektierten Kontextdaten, mit denen
+ eine (Orts-)Clusterung durchgeführt werden kann. Für diese Anforderungen ist eine
+ (Orts-)Clusterung gemäß DBSCAN-Verfahren geeignet (Density-Based Spatial Clustering of
+ Applications with Noise). Der von Ester et al. beschriebene Algorithmus besagt, dass
+ jeder Datenpunkt für sich betrachtet werden soll; ist er noch nicht klassifiziert
+ wird die Bildung eines neuen (Orts-)Clusters oder die Zuordnung zu einem bestehenden
+ angestoßen.<note type="footnote">
+ Vgl. <ref type="bibliography" target="#ester_noise_1996">Ester et al. 1996</ref>, S. 229.</note> In Anlehnung daran ist eine
+ (Orts-)Clusterung auch für die Kontextdaten realisiert (siehe Funktion <code>qualityChecker()</code>). Um die Parameter der (Orts-)Clusterung anzupassen ist eine
+ Betrachtung der Streuung der (Orts-)Cluster in einzelnen GEDCOM-Dateien von Interesse. Zum
+ einen kann die Mindestanzahl von Orten variiert werden, die nötig sind, um ein
+ (orts-)Cluster zu bilden. Zum anderen ist die Mindestdistanz entscheidend, die ein Ort von
+ einem (Orts-)Cluster entfernt sein muss, um diesem nicht zugeschlagen zu werden. Im
+ Folgenden wird dieses für die GEDCOM-Dateien untersucht.<note type="footnote"> Bei der Validierung durch andere
+ Quellen würden gegebenenfalls andere Ergebnisse resultieren.</note> Bei
+ einem Vergleich der Mittelpunkte von (Orts-)Clustern einer Quelle bei Variation der
+ Parameter (Kilometer zur Zusammenführung zweier Orte, Mindestanzahl von Orten für
+ ein (Orts-)Cluster, siehe <ref type="graphic" target="#urbanonyme_2020_014">Abbildung 14</ref>) zeigt sich,
+ dass eine Distanz von 10 km (links) dazu führt, dass es sehr viele (Orts-)Cluster gibt, die
+ nah beieinander liegen. Dieses ist ein unerwünschter Effekt, da diese (Orts-)Cluster aus
+ der Perspektive des gesamten deutschen Sprachraumes zu wenig voneinander entfernt
+ sind. Es deutet sich ein weiteres lokales Maximum bei der Distanz von etwa 450 km
+ an. Auch bei 25 km zeigt sich dieses Bild (Mitte), allerdings in sehr abgeschwächter
+ Form. Erst bei 50 km ist der starke Anstieg nach Erreichen des Mindestabstandes
+ abgeflacht (rechts). Der Erwartungswert der Verteilung liegt etwa bei 450 km.
+ Gleiches gilt bei einer Variation der Mindestanzahl an Koordinatendatenpunkten je
+ (Orts-)Cluster zu erkennen. Hierdurch wird jedoch die absolute Zahl der (Orts-)Cluster stark
+ geschrumpft.</p>
+ <figure>
+ <graphic xml:id="urbanonyme_2020_014" url="Medien/urbanonyme_2020_014.png">
+ <desc>
+ <ref target="#abb14">Abb. 14</ref>: Anzahl an

 (Orts-)Clustern nach durchschnittlichem Abstand in km bei Variation des Mindestabstandes zwischen
 (Orts-)Clustern (10 km, 25 km, 50 km) und Mindestgröße von (Orts-)Clustern (2, 6, und 11), jeweils 200 Bins, Abszisse beschreibt den Abstand in km, Ordinate die Anzahl an (Orts-)Clustern. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_014"/>
+ </desc>
+ </graphic>
+ </figure>
+ <p>Bei einer Betrachtung der Anzahl von
+ (Orts-)Clustern pro Datei für jede dieser neun Optionen ergibt sich, dass die
+ unterschiedlichen Optionen vor allem bei Dateien mit vielen (Orts-)Clustern eine Auswirkung
+ aufzeigen. Liegen eine geringere Mindestgröße und ein geringer Minimalabstand
+ zwischen zwei Punkten von (Orts-)Clustern vor, erhöht sich die Anzahl der gesamten (Orts-)Cluster
+ stark (siehe <ref type="graphic" target="#urbanonyme_2020_015">Abbildung 15</ref>). Das bedeutet, dass
+ bei einer niedrigen Mindestdistanz sehr viele nah beieinanderliegende (Orts-)Cluster
+ existieren. Aus diesem Grund wurde die Mindestdistanz von 50 km gewählt. Als
+ Mindestgröße eines (Orts-)Clusters wird >5 gewählt, um einerseits die starke Erhöhung
+ der (Orts-)Clusteranzahl bei einem weiteren Absenken der Mindestgröße zu vermeiden, auf der
+ anderen Seite aber auch in wenig umfangreichen Dateien eine (Orts-)Clusterbildung zu
+ ermöglichen. </p>
+ <figure>
+ <graphic xml:id="urbanonyme_2020_015" url="Medien/urbanonyme_2020_015.png">
+ <desc>
+ <ref target="#abb15">Abb. 15</ref>: Zusammenhang
 zwischen Mindestdistanz, Mindest(orts-)clustergröße und (Orts-)Clusteranzahl, links mit
 logarithmischer Skalierung. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_015"/>
+ </desc>
+ </graphic>
+ </figure>
+ <p>Definiert wird also, dass ein (Orts-)Cluster
+ mindestens aus sechs Orten bestehen muss. Ferner muss jeder Ort eines (Orts-)Clusters 50
+ Kilometer von dem Ort eines anderen (Orts-)Clusters entfernt liegen; ansonsten würden sie
+ in einem gemeinsamen (Orts-)Cluster zusammengeführt. Es zeigt sich, dass dadurch 66 Prozent
+ der GEDCOM-Dateien, die überhaupt ein (Orts-)Cluster aufweisen,<note type="footnote"> 52 Prozent GEDCOM-Dateien weisen
+ kein (Orts-)Cluster auf. Das liegt darin begründet, dass kein (Orts-)Cluster von
+ mindestens fünf Ortsangaben gebildet werden konnte.</note> nur ein
+ einziges (Orts-)Cluster aufweisen, das den oben definierten Eigenschaften (50 km, mind. 6
+ zusammenhängende Orte) entspricht. 19 Prozent jedoch weisen zwei (Orts-)Cluster auf, 15
+ Prozent sogar mehr als zwei. Die Entfernung der Optionen einer unidentifizierten
+ Ortsangabe werden für alle (Orts-)Clustermittelpunkte berechnet. Der Ort mit der geringsten
+ Distanz zu einem der (Orts-)Clusterpunkte wird für die Identifizierung gewählt.</p>
+ <p>Ein weiterer Bestandteil der
+ Validierung bezieht sich auf die Ähnlichkeitsanalyse. Diese ist zwar nicht primär
+ zum kontextbasierten Aspekt des Algorithmus zu zählen, wird aufgrund der Relevanz
+ für das Gesamtergebnis aber trotzdem diskutiert. Die Ortsangaben, zu denen keine
+ Übereinstimmung gefunden werden konnten, werden einer Ähnlichkeitsanalyse
+ unterzogen. Dazu werden zwei Varianten verglichen. Zum einen ist das die
+ Levenshtein-Distanz (bereits in <ref type="intern" target="#hd4">Abschnitt 2.2</ref>
+ erläutert). Zum anderen wird ein Maß gesetzt, dass sich hierarchisch auf
+ verschiedene Bestandteile stützt: Zunächst werden vertauschte Zeichen erkannt, indem
+ die 61 Orte<note type="footnote"> Siehe
+ hierzu Anm. 41.</note> einer Anagrammdetektion unterzogen werden.<note type="footnote"> Der Nachteil dieses
+ Vorgehens liegt auch hier darin, dass vertauschte Zeichen am Anfang der
+ Zeichenkette nicht erkannt werden, weil sie in einer alphabetischen
+ Sortierung weit entfernt sind. Zudem erkennt eine Ähnlichkeitsanalyse durch
+ ein Anagramm nur vertauschte Zeichen, nicht aber ausgelassene oder
+ zusätzlich vorhandene Buchstaben.</note> Falls kein Anagramm erkannt
+ wird, werden zunächst aufeinanderfolgende doppelte Buchstaben in beiden
+ Zeichenketten entfernt. Sind diese dann gleich, besteht eine Zuordnung. Ist das
+ nicht der Fall, so wird mit dem verbleibenden Zeichen ein Vergleich nach der Kölner
+ Phonetik angestellt. Bei einem gleichen Ergebnis findet eine Auswahl statt.</p>
+ <p>Bei einem initialen Grenzwert von 0,25
+ (Verhältnis von Anzahl der Änderungen zur Länge der Zeichenkette<note type="footnote"> Bei der Kölner Phonetik wird dazu
+ die Levenshtein-Distanz der ursprünglichen Zeichenketten
+ herangezogen.</note>) ergeben sich sowohl bei der Levenshtein-Distanz als
+ auch bei dem alternativen Maß viele Falschpositive (75 bzw. 74 Prozent). Ein
+ Großteil dieser ist zum einen durch Ortsangaben zu Orten außerhalb des
+ Betrachtungsgebietes bedingt, die dennoch deutschen Ortsnamen ähneln. Zum anderen
+ sind dort überproportional viele Bezeichnungen vorhanden, die Orte in den ehemaligen
+ Ostgebieten beschreiben und bei denen die zeitliche Konsistenz der Ortsbezeichnung
+ (u. a. aufgrund von Umbenennungen) gering ist. Auch liegt das darin begründet, dass
+ Ortsbezeichnungen teilweise sehr ähnlich sind.<note type="footnote"> Bei einer zulässigen Levenshtein-Distanz von 2
+ sind beispielsweise Orte wie Nehmten und Nehren, Neiden und Nehren, Bövingen
+ und Böttingen, Muron und Murr, Murow und Murr, Balden und Belsen, Weißstein
+ und Beilstein oder Hattingen und Böttingen als gleich anzusehen. Selbst bei
+ einer Verringerung der Toleranz auf eine Distanz von 1 würden viele
+ FP-Ergebnisse produziert, beispielsweise bei Nehden und Nehren, Bötzingen
+ und Böttingen oder Oderthal und Odenthal.</note> Vermeintlich korrekte
+ TP-Ergebnisse (z. B. ›Stuttgardt‹ zugeordnet zu ›Stuttgart‹) sind in der Minderheit.
+ Aus diesem Grund wird die Grenze auf 0,17 (ab sechs Buchstaben eine Veränderung, ab
+ 12 Buchstaben zwei Veränderungen etc.) verringert. In der Folge kommt die
+ Ähnlichkeitsanalyse über die Levenshtein-Distanz etwa bei jedem sechsten Fall zu
+ einem Ergebnis, das alternative Maß in jedem fünften Fall (siehe <ref type="intern" target="#tab03">Tabelle 3</ref>). Bei 9,34 bzw. 11,90 Prozent
+ ergeben sich mehrere Übereinstimmungen, von denen eine ausgewählt wird. Beide
+ Ähnlichkeitsanalysen produzieren mehr falsche als richtige Ergebnisse. Dieses zeigt,
+ dass die Ähnlichkeitsanalyse insbesondere bei einer schlechten Datenqualität und vor
+ dem Hintergrund einer großen Ähnlichkeit von Ortsbezeichnungen eine Herausforderung
+ ist, die hier nicht zur vollkommenen Zufriedenheit gelöst werden kann. Künftige
+ Forschungen sollten sich diesem Aspekt verstärkt annehmen. Aber auch wenn der Wert
+ bezogen auf die GEDCOM-Dateien nicht zufriedenstellend ist, so sollte dieses Element
+ im Algorithmus dennoch beibehalten werden. Es ist zu erwarten, dass bei anderen
+ Quellen mit einer besseren Datenqualität auch eine bessere Erkennung
+ einhergeht.<note type="footnote">
+ Eine Idee für die künftige Erweiterung des Algorithmus besteht darin, dass
+ unklare Ortsangaben zunächst innerhalb des Kontextes verglichen werden.
+ Insbesondere in GEDCOM-Dateien besteht eine hohe Wahrscheinlichkeit, dass
+ Orte doppelt genannt werden; Schreibfehler könnten hierüber gegebenenfalls
+ effektiv erkannt werden.</note> Da der alternative Vergleich über
+ Anagramme und die Kölner Phonetik bessere Werte (mehr TP-Ereignisse<note type="footnote"> Zur Ermittlung
+ wurden 100 zufällige Ergebnisse ausgewählt und manuell eingeschätzt, ob es
+ sich um ein richtiges oder falsches Ergebnis handelt.</note>) aufweist,
+ wird diese Alternative im Weiteren ausgewählt.</p>
+ <table>
+ <row>
+ <cell>Ähnlichkeitsmaß</cell>
+ <cell>Erkennung = 1</cell>
+ <cell>FP</cell>
+ <cell>TP</cell>
+ <cell>Erkennung > 1<note type="footnote"> Die Angabe zu den Falschpositiven und
+ Falschnegativen bezieht sich zudem auf die nachfolgende Auswahllogik
+ eines der erkannten Orte (anhand geographischer Nähe, Typ etc.); nur
+ dieses wird untersucht.</note>
+ </cell>
+ <cell>FP</cell>
+ <cell>TP</cell>
+ </row>
+ <row>
+ <cell>Levenshtein-Distanz</cell>
+ <cell>6,23 %</cell>
+ <cell>68</cell>
+ <cell>32</cell>
+ <cell>9,34 %</cell>
+ <cell>71</cell>
+ <cell>29</cell>
+ </row>
+ <row>
+ <cell>Anagramm und Kölner
+ Phonetik</cell>
+ <cell>7,22 %</cell>
+ <cell>65</cell>
+ <cell>35</cell>
+ <cell>11,90 %</cell>
+ <cell>67</cell>
+ <cell>33</cell>
+ </row>
+ <trailer xml:id="tab03">
+ <ref type ="intern" target="#tab3">Tab. 3</ref>: Vergleich

+ verschiedener Ähnlichkeitsmaße, alle Angaben in Prozent, Grenze: 0,17. [Goldberg
+ 2022]<ref type="graphic" target="#urbanonyme_2020_t3"/>
+ </trailer>
+ </table>
+ <p>Eine Ausführung des Algorithmus unter
+ den oben festgelegten Variationen ergibt das in <ref type="intern" target="#tab04">Tabelle 4</ref> dargestellte Ergebnis. 49,72 Prozent der Urbanonyme wird ein
+ GOV-URI zugeordnet, 50,28 Prozent hingegen nicht. Der prozentuale Anteil der jeweils
+ möglichen Ereignisse zeigt, dass fast jedes dritte Urbanonym dem weiteren Verfahren
+ entzogen wird, weil es unerlaubte Bestandteile enthält. In diesem Fall sind die unerlaubten Bestandteile vor allem Hinweise auf eine Angabe außerhalb des Betrachtungsgebiets (z. B. Kürzel von
+ US-Bundesstaaten), die in den vorliegenden Daten sehr häufig vorkommen. Bei anderen Daten können die unerlaubten Bestandteile entsprechend angepasst werden. Die kontextbasierte Auswahl auf Basis der geographischen Nähe
+ bekommt daher eine hohe Relevanz. Auffällig ist auch der hohe Anteil an Ortsangaben,
+ zu denen kein Pendant (also auch keine Ähnlichkeit) zu den Orten des Mini-GOVs
+ vorhanden ist. Dem zugrunde liegen viele Berufsangaben und Orte außerhalb des
+ Betrachtungsgebiets, aber auch vermeintlich korrekte Ortsangaben, die in einem
+ unüblichen Format vorliegen (z. B. als Wikipedia-Verlinkung) oder sehr falsch
+ geschrieben sind. Ansonsten finden sich auch hier überproportional viele Angaben,
+ die auf ehemalige deutsche Ostgebiete hinweisen und nicht in der Ausführlichkeit im
+ Mini-GOV gepflegt sind. Wenig relevant sind dagegen die Fälle, die die Typen der
+ Objekte einbeziehen. Von diesen ist einzig allein die Option, bei der nur ein Objekt
+ einen passenden Typ besitzt, mit 7,44 Prozent bedeutend.</p>
+ <table>
+ <row>
+ <cell>Auswahlkriterium</cell>
+ <cell>Anteil
+ in Prozent</cell>
+ </row>
+ <row>
+ <cell>Unerlaubte Bestandteile</cell>
+ <cell>31,51</cell>
+ </row>
+ <row>
+ <cell>Unerlaubter Angabe</cell>
+ <cell>0,07</cell>
+ </row>
+ <row>
+ <cell>Einziger passender Treffer in
+ Ähnlichkeitsanalyse</cell>
+ <cell>2,05</cell>
+ </row>
+ <row>
+ <cell>Einziger mit Koordinaten nach
+ Ähnlichkeitsanalyse</cell>
+ <cell>0,58</cell>
+ </row>
+ <row>
+ <cell>Geographische Nähe nach
+ Ähnlichkeitsanalyse</cell>
+ <cell>2,42</cell>
+ </row>
+ <row>
+ <cell>Einziger gültiger Typ nach
+ Ähnlichkeitsanalyse</cell>
+ <cell>0,02</cell>
+ </row>
+ <row>
+ <cell>Keiner mit gültigem Typ nach
+ Ähnlichkeitsanalyse</cell>
+ <cell>0,00</cell>
+ </row>
+ <row>
+ <cell>Ein passender Typ nach
+ Ähnlichkeitsanalyse</cell>
+ <cell>0,05</cell>
+ </row>
+ <row>
+ <cell>Zu viele passende Typen nach
+ Ähnlichkeitsanalyse</cell>
+ <cell>0,00</cell>
+ </row>
+ <row>
+ <cell>Ein einziger passender
+ Treffer</cell>
+ <cell>11,25</cell>
+ </row>
+ <row>
+ <cell>Ein einziger Treffer mit
+ Koordinaten</cell>
+ <cell>6,53</cell>
+ </row>
+ <row>
+ <cell>Geographische Nähe</cell>
+ <cell>18,87</cell>
+ </row>
+ <row>
+ <cell>Einziger gültigen Typ</cell>
+ <cell>0,41</cell>
+ </row>
+ <row>
+ <cell>Keiner mit gültigem Typ</cell>
+ <cell>0,05</cell>
+ </row>
+ <row>
+ <cell>Ein passender Typ</cell>
+ <cell>7,44</cell>
+ </row>
+ <row>
+ <cell>Zu viele passende Typen</cell>
+ <cell>0,00</cell>
+ </row>
+ <row>
+ <cell>Kein Auswahlkriterium
+ entscheidend</cell>
+ <cell>0,48</cell>
+ </row>
+ <row>
+ <cell>Kein Pendant im Mini-GOV
+ gefunden</cell>
+ <cell>18,17</cell>
+ </row>
+ <trailer xml:id="tab04">
+ <ref type ="intern" target="#tab4">Tab. 4</ref>: Endzustände des

+ Algorithmus am Beispiel Ortsangaben in GEDCOM-Dateien, Grundgesamtheit von 262.741
+ Einträgen.<note type="footnote"> Die

+ erhebliche Verkleinerung der Anzahl zu untersuchender Ortsangaben (von

+ 3.057.810 auf 262.741) ist auf die Löschung doppelter Ortsangaben in einer

+ Datei zurückzuführen.</note> [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_t4"/>
+ </trailer>
+ </table>
+ <p>Eine Stichprobe von 100 Werten
+ erbrachte 36 TP-Werte<note type="footnote"> Erkannte Orte aus den nicht-deutschen Mini-GOVs fallen
+ in diese Kategorie.</note>, 42 TN-Werte, 11 FP-Werte<note type="footnote"> Nicht erkannte Orte aus den
+ nicht-deutschen Mini-GOVs fallen in diese Kategorie.</note> und 11
+ FN-Werte.<note type="footnote"> Die
+ für die Einordnung in die vier Kategorien notwendige manuelle
+ Klassifizierung basierte dabei auf der Hinzunahme von Informationen, die bei
+ der Bereinigung gelöscht wurden sowie dem Aufrufen der GEDCOM-Datei und
+ Vergleich mit den Orten der näheren Verwandtschaft (nicht wie im Algorithmus
+ mit den (Orts-)Clustern der Quelle generell). Ortsbezeichnungen in den Ländern der
+ inkludierten Mini-GOVs wurden hierbei wie Orte in Deutschland
+ behandelt.</note> Der hohe Anteil an Falschnegativen ist dadurch zu
+ erklären, dass das Mini-GOV nicht alle Orte oder Varianten enthält (insbesondere in
+ ehemaligen deutschsprachigen Siedlungsgebieten). Die Gründe für eine wahrnegative
+ Lokalisierung hingegen sind überwiegend dadurch bedingt, dass Ortsangaben außerhalb
+ des Betrachtungsgebiets als solche erkannt werden. Insgesamt sind also 78 Prozent
+ der Ortsangaben korrekt und 22 Prozent nicht korrekt behandelt worden.</p>
+ <p>Der zweite Teil der Validierung
+ bezieht sich auf die (Orts-)Clusterung der GOV-URIs zu den Provinzen. Bei insgesamt 68.011
+ GOV-URIs wurde versucht, mit dem Algorithmus eine Provinz zum Jahr 1820 zuzuordnen.
+ Bei 46.877 GOV-URIs (69 Prozent) war die Zuordnung erfolgreich. Der hohe Anteil an
+ nicht zugeordneten GOV-URIs ist jedoch diskussionswürdig. Aus diesem Grund wurden
+ 100 zufällige nicht zuordenbare GOV-URIs manuell überprüft.<note type="footnote"> Dieser Schritt wurde im Verlauf
+ der Erarbeitung iterativ durchgeführt, um ungünstige Funktionen des
+ Programmcodes zu entdecken und zu verbessern.</note> Die Fehler sind in
+ <ref type="intern" target="#tab05">Tabelle 5</ref> dargestellt.</p>
+ <table>
+ <row>
+ <cell>Grund
+ der fehlgeschlagenen Klassifizierung</cell>
+ <cell>Anzahl</cell>
+ </row>
+ <row>
+ <cell>
+ <p>Ort liegt außerhalb der Zielprovinzen
+ </p>
+ <p>(In heutigen
+ Staaten: Niederlande 29x, Frankreich 12x, Österreich 9x, Tschechien 5x,
+ Schweiz 3x, Polen 3x, Dänemark 1x)</p>
+ </cell>
+ <cell>62</cell>
+ </row>
+ <row>
+ <cell>
+ <p>GOV-Daten sind unvollständig</p>
+ <p>(Klassifiziert nach den
+ heutigen Bundesländern: Schleswig-Holstein 12x, Rheinland-Pfalz 7x,
+ Saarland 4x, Sachsen 2x, Baden-Württemberg 2x, Hessen 2x, Bayern 1x,
+ Thüringen 1x, Sachsen-Anhalt 1x)</p>
+ </cell>
+ <cell>32</cell>
+ </row>
+ <row>
+ <cell>Ausgestaltung des Algorithmus
+ deckt Fall nicht ab</cell>
+ <cell>6</cell>
+ </row>
+ <trailer xml:id="tab05">
+ <ref type="intern" target="#tab5">Tab. 5</ref>: Fehler in der
 Zuordnung der Provinzen bei der Bezugszeit 1820. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_t5"/>
+ </trailer>
+ </table>
+
+ <p>Es zeigt sich, dass der wesentliche
+ Grund für den hohen Grad der Nicht-Erkennung darin liegt, dass die Objekte außerhalb
+ des relevanten Zielgebiets liegen oder aber die GOV-Daten nicht vollständig sind.
+ Letzteres betrifft vor allem die Orte in den heutigen Bundesländern
+ Schleswig-Holstein, Rheinland-Pfalz und im Saarland. Hochgerechnet etwa 94 Prozent
+ der Fehler liegen als nicht primär im Algorithmus begründet. Daraus ergibt sich eine
+ Trefferquote von 97 Prozent<note type="footnote">
+ [Anzahl gefundener Provinzen] ÷ [Anzahl
+ gefundener Provinzen + (1 – Anteil Fehler) × Anzahl nicht gefundener
+ Provinzen].</note> für die gesamte Provinzenzuordnung bezogen
+ auf die GOV-URIs im Betrachtungsgebiet bei denen das GOV vollständig gepflegt ist.
+ Hier zeigt sich, dass das GOV bereits eine breite Datengrundlage enthält und viele
+ Fälle abdecken kann, jedoch in Bezug auf die historischen Verwaltungszugehörigkeiten
+ auch künftig weiter komplettiert werden sollte. </p>
+ <p>Bei einer Änderung der Bezugszeit auf
+ das Jahr 2020 ergibt sich ein ähnliches Bild (siehe <ref type="intern" target="#tab06">Tabelle 6</ref>). Auffällig ist, dass die GOV-Verwaltungszugehörigkeiten hier
+ vollständiger sind. Am deutlichsten ist das bei Schleswig-Holstein. Für die
+ Bezugszeit 2020 ergibt sich eine Trefferquote von 96 Prozent. Die Fehler sind
+ allerdings etwas anders bedingt. Zwar sind sie auch darauf zurückzuführen, dass das
+ GOV unvollständig ist. Das Bundesland ist jedoch (anders als oben) Teil der
+ übergeordneten Objekte; lediglich die Dauer der Zugehörigkeit ist nicht gepflegt.
+ Das tritt bei einzelnen Orten in Bayern und in Schleswig-Holstein um Lübeck herum
+ auf.</p>
+ <table>
+ <row>
+ <cell>Grund
+ der fehlgeschlagenen Klassifizierung</cell>
+ <cell>Anzahl</cell>
+ </row>
+ <row>
+ <cell>
+ <p>Ort liegt außerhalb der Zielprovinzen
+ </p>
+ <p>(In heutigen
+ Staaten: Niederlande 41x, Polen 22x, Österreich 12x, Tschechien 10x,
+ Frankreich 5x, Schweiz 2x, Dänemark 1x)</p>
+ </cell>
+ <cell>93</cell>
+ </row>
+ <row>
+ <cell>
+ <p>Ausgestaltung des Algorithmus deckt Fall
+ nicht ab</p>
+ <p>(Klassifiziert nach den heutigen Bundesländern: Schleswig-Holstein 3x,
+ Bayern 3x, Rheinland-Pfalz 1x)</p>
+ </cell>
+ <cell>7</cell>
+ </row>
+ <trailer xml:id="tab06">
+ <ref type="intern" target="#tab6">Tab. 6</ref>: Fehler in der
 Zuordnung der Provinzen bei der Bezugszeit 2020. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_t6"/>
+ </trailer>
+ </table>
+ <p>Insgesamt werden mit dem Algorithmus –
+ unabhängig der beiden getesteten Bezugszeiten – etwa drei von vier Ortsangaben
+ richtig identifiziert und lokalisiert. Werden die Ortsangaben isoliert betrachtet,
+ die einer Provinz zugeordnet werden, so sind hier ebenfalls etwa drei von vier
+ Zuordnungen korrekt. Fast jede identifizierte Ortsangabe kann nachfolgend auch
+ regional geclustert werden.</p>
+ </div>
+ <div type="chapter">
+ <head>6. Zusammenfassung</head>
+
+ <p>Ob das Neustadt an der Aisch oder in
+ Sachsen, an der Weinstraße oder in Hessen gemeint ist, kann durch den vorgestellten
+ Algorithmus nun ermittelt werden – er trifft eine Entscheidung ohne menschliches
+ Zutun. Grundlage hierfür stellt der Kontext dar, in dem die Bezeichnung des Ortes
+ genannt wird. Die Kontextsensitivität wird dadurch erreicht, dass ein Bezug zu
+ anderen Ortsangaben in der gleichen Quelle hergestellt wird. Die grundlegende
+ Heuristik dahinter besagt: Gemeinsam genannte Orte liegen beieinander. Durch die
+ Formalisierung und Automatisierung dieser Heuristik ergibt sich eine
+ kontextsensitive Anwendung, die auf verschiedenen wissenschaftlichen Gebieten
+ genutzt werden kann. Der Algorithmus trifft bei Anwendung auf die GEDCOM-Dateien der
+ öffentlich zugänglichen genealogischen Datenbank GEDBAS – nach einer Bereinigung –
+ in drei von vier Fällen eine korrekte Entscheidung. Das ist vor dem Hintergrund ein
+ guter Wert, dass die Daten oftmals eine schlechte Qualität aufweisen, kein Standard
+ in der Benennung praktiziert wird und sie Urbanonyme aus aller Welt enthalten,
+ wenngleich der Schwerpunkt im zentraleuropäischen Raum zu verorten ist.</p>
+ <p>Die Ortsbezeichnungen werden mithilfe
+ des Kontextes identifiziert, durch die Bestimmung der Koordinaten lokalisiert und
+ anschließend in einer (historischen) Provinz regional geclustert. Für den letzten
+ Aspekt ist eine Bezugszeit zu definieren. Der Algorithmus ist derzeit darauf
+ ausgelegt, Orte innerhalb des deutschsprachigen Raums (ohne Österreich und die
+ Schweiz) in den Grenzen von 1815 bis 1871 sowie ab 1990 zuzuordnen. In diesem Rahmen
+ kann sich auch die Bezugszeit bewegen. Dazu wird das <bibl>
+ <title type="desc">Geschichtliche Orts-Verzeichnis</title>
+ </bibl> (GOV) genutzt, ein geographisches Lexikon,
+ das stetig erweitert wird. Die Zuordnung zu einer definierten Provinz gelingt in 70
+ Prozent der Fälle. Werden diejenigen Fehler herausgefiltert, die auf einer
+ unvollständigen Datengrundlage und Orten außerhalb des Betrachtungsgebiets basieren,
+ ergibt sich eine Zuordnungsrate von 96 Prozent.</p>
+ <p>Zusammengefasst werden drei von vier
+ relevanten Ortsangaben lokalisiert, wovon wiederum drei Viertel korrekt sind. Ãœber
+ 90 Prozent der Orte im Betrachtungsgebiet können nachfolgend regional geclustert
+ werden. Der Algorithmus bietet damit eine geeignete Grundlage, um ihn an
+ verschiedene Anwendungsszenarien anzupassen. Er stellt dadurch ein frei verfügbares
+ Werkzeug insbesondere für wirtschafts- und sozialgeschichtliche Untersuchungen dar.
+ Er kann prädestiniert dafür eingesetzt werden, Fragen der räumlichen Mobilität zu
+ erörtern oder einzelne Datensätze in historischen Provinzen zu klassifizieren. Vor
+ allem der Einsatz in kilometrischen Studien ist vorstellbar. Vorteile ergeben sich
+ insbesondere in der Verarbeitung von Massendaten, wodurch neue Perspektiven für die
+ Wissenschaft eröffnet werden. Er ist besonders dann vorteilhaft, wenn viele
+ Ortsangaben im Kontext erfasst sind. Das ist u. a. der Fall, wenn zahlreiche
+ zusammenhängende Orte ausgewertet und lokalisiert werden müssen. Zur Validierung des
+ Algorithmus wurden zwar genealogische Daten genutzt. Prinzipiell ist der Algorithmus
+ aber bei all solchen Quellen empfehlenswert, bei denen im Kontext weitere
+ Ortsbezeichnungen genannt werden und ein räumlicher Zusammenhang nicht explizit
+ verneint werden kann.<note type="footnote"> Der Algorithmus sollte zudem nicht auf antike oder
+ mittelalterliche Quellen angewendet werden, da die hier verwendete
+ Referenzdatenbank, das GOV, keine Daten über solch frühe Strukturen enthält.
+ Darüber hinaus bestehen andere Herausforderungen, die einer gesonderten
+ Betrachtung bedürfen. Die Idee der kontextsensitiven Entscheidungsfindung
+ über geographische Distanzen kann jedoch auch bei solchen Quellen Anwendung
+ finden.</note>
+ </p>
+ <p>Derzeit deckt der Algorithmus den
+ historischen deutschen Sprachraum ab. Da Informationen des GOVs auch für weitere
+ europäische Länder verfügbar sind, könnten diese samt der dazugehörigen Regionen
+ folgend integriert werden. Der Algorithmus ist zwar auf die deutsche Sprache
+ ausgelegt (z. B. der Einsatz der Kölner Phonetik und die String-Bereinigungsregeln).
+ Dennoch könnte er auf weitere Länder / Sprachen angepasst werden. Auch ist eine
+ Weiterentwicklung des Kontextbezugs denkbar. Ein Beispiel dafür stellen die im
+ Kontext genannten Vor- und Familiennamen dar. Voraussetzung hierfür ist eine
+ vorhergehende Erstellung einer Datenbasis über die zeitliche und räumliche
+ Verbreitung von Personennamen, auf die sich der Algorithmus beziehen kann.</p>
+ </div>
+ <div type="bibliography">
+ <head>Bibliographische Angaben</head>
+ <listBibl><bibl xml:id="abowd_context-awareness_1999">Gregory Dominic Abowd / Anind
+ K. Dey / Peter J. Brown / Nigel Davies / Mark Smith / Pete Steggles: Towards a
+ Better Understanding of Context and Context-Awareness. In: Handheld and
+ Ubiquitous Computing. Hg. von Hans-Werner Gellersen. Berlin / Heidelberg 1999.
+ S. 304-307. <ptr type="gbv" cRef="302206205"/></bibl>
+ <bibl xml:id="adwul_familienatlas">Akademie der Wissenschaften und Literatur Mainz / Albert-Ludwigs-Universität Freiburg (Hg.): Deutscher Familienatlas. 2009–2018. [<ref target="https://www.namenforschung.net/dfa/projekt/">online</ref>] </bibl>
+ <bibl xml:id="baehr_bevoelkerungsgeographie_1992">Jürgen Bähr / Christoph Jentsch / Wolfgang Kuls:
+ Bevölkerungsgeographie. Berlin u. a. 1992. <ptr type="gbv" cRef="028380339"/></bibl>
+ <bibl xml:id="clarke_principles_2009">Bertrand Clarke / Ernest Fokoue / Hao Helen Zhang:
+ Principles and Theory for Data Mining and Machine Learning. Dordrecht u. a. 2009. (=
+ Springer Series in Statistics) <ptr type="gbv" cRef="593579658"/> </bibl>
+ <bibl xml:id="ester_noise_1996">Martin Ester / Hans-Peter Kriegel / Xiaowei Xu: A
+ Density-Based Algorithm for Discovering Clusters in Large Spatial Databases with
+ Noise. In:
+ Proceedings. Second
+ International Conference on Knowledge Discovery & Data Mining. Hg. von Evangelos
+ Simoudis / Jiawei Han / Usama Fayyad (KDD-96: 2, Portland, OR, 02.–04.08.1996) Menlo
+ Park, CA 1996. PDF. [<ref target="https://www.dbs.ifi.lmu.de/Publikationen/Papers/KDD-96.final.frame.pdf">online</ref>] <ptr type="gbv" cRef="223215147"/></bibl>
+ <bibl xml:id="fawcett_introduction_2006">Tom Fawcett: An introduction to ROC analysis. In: Pattern
+ Recognition Letters 27 (2006), H. 8, S. 861–874. <ptr type="gbv" cRef="129161756"/></bibl>
+ <bibl xml:id="feigenbaum_computers_1963">Computers and thought. Hg. von Edward A. Feigenbaum /
+ Julian Feldman. New York, NY u. a. 1963. <ptr type="gbv" cRef="020732821"/></bibl>
+ <bibl xml:id="fertig_zeitalter_2018">Georg Fertig / Christian Schlöder / Rolf Gehrmann /
+ Christina Langfeldt / Ulrich Pfister: Das postmalthusianische Zeitalter: Die
+ Bevölkerungsentwicklung in Deutschland, 1815–1871. In: Vierteljahrschrift für
+ Sozial- und Wirtschaftsgeschichte 105 (2018), H. 1, S. 6–33. <ptr type="gbv" cRef="129459623"></ptr></bibl>
+ <bibl xml:id="gallagher_estimating_2008">Andrew C. Gallagher / Tsuhan Chen: Estimating age, gender,
+ and identity using first name priors. In: IEEE Conference on Computer Vision and
+ Pattern Recognition (2008). DOI: <ref target="https://doi.org/10.1109/CVPR.2008.4587609">10.1109/CVPR.2008.4587609</ref> <ptr type="gbv" cRef="577792776"/></bibl>
+ <bibl xml:id="gellatly_reconstructing_2015">Corry Gellatly: Reconstructing Historical Populations from
+ Genealogical Data Files. In: Population Reconstruction. Hg. von Gerrit Bloothooft /
+ Peter Christen / Kees Mandemakers / Marijn Schraagen. Cham u. a. 2015, S. 111–128.
+ <ptr type="gbv" cRef="833549804"/></bibl>
+ <bibl xml:id="gentile_techniques_2013">Geolocation Techniques: Principles and Applications. Hg.
+ von Camillo Gentile / Nayef Alsindi / Ronald Raulefs / Carole Teolis. New York, NY
+ u. a. 2013. <ptr type="gbv" cRef="73135057X"/></bibl>
+ <bibl xml:id="gesellschaft_vornamen_2019">Ausführliche Auswertung: Vornamen 2018. Hg. von
+ Gesellschaft für deutsche Sprache e. V. In: gfds.de. Wiesbaden u. a. 2019.
+ Pressemitteilung vom 02.05.2019. [<ref target="https://gfds.de/ausfuehrliche-auswertung-vornamen-2018/">online</ref>] </bibl>
+ <bibl xml:id="gigerenzer_heuristics_1999">Simple Heuristics that make us smart. Hg. von Gerd
+ Gigerenzer / Peter M. Todd. New York, NY u. a. 1999. <ptr type="gbv" cRef="252837991"/></bibl>
+ <bibl xml:id="goldberg_extraktion_2021">Jan Michael Goldberg / Katrin Moeller: Automatisierte
+ Extraktion und Lemmatisierung historischer Berufsbezeichnungen in deutschsprachigen
+ Datenbeständen. In: Zeitschrift für digitale Geisteswissenschaften 6 (2021). DOI: <ref target="https://doi.org/10.17175/2022_002">10.17175/2022_002</ref></bibl>
+ <bibl xml:id="harviainen_genealogy_2018">J. Tuomas Harviainen / Bo-Christer Björk: Genealogy,
+ GEDCOM, and popularity implications. In: Informaatiotutkimus 37 (2018), H. 3, S.
+ 4–14. DOI: <ref target="https://doi.org/10.23978/inf.76066">10.23978/inf.76066</ref>
+ </bibl>
+ <bibl xml:id="institut_ortsverzeichnis_2020">Das Historische Ortsverzeichnis von Sachsen. Hg. von
+ Institut für sächsische Geschichte und Volkskunde. In: hov.isgv.de. Dresden 2020.
+ [<ref target="https://hov.isgv.de/">online</ref>] </bibl>
+ <bibl xml:id="kocka_familie_1980">Jürgen Kocka / Karl Ditt / Josef Mooser / Heinz Reif /
+ Reinhard Schüren: Familie und soziale Plazierung. Studien zum Verhältnis von
+ Familie, sozialer Mobilität und Heiratsverhalten an westfälischen Beispielen im
+ späten 18. und 19. Jahrhundert. Opladen 1980. <ptr type="gbv" cRef="023831081"/></bibl>
+ <bibl xml:id="levenstejn_codes_1966">Vladimir IosifoviÄ LevenÅ¡tejn: Binary Codes Capable of
+ Correcting Deletions, Insertations, and Reversals. Soviet Physics /Doklady 10
+ (1966), H. 8, S. 707–710. <ptr type="gbv" cRef="129482234"/></bibl>
+ <bibl xml:id="list_distanz_2010">Johann-Mattis List: Distanz- und Alignmentanalysen in
+ derhistorischen Linguistik. Düsseldorf 2010. PDF. [<ref target="http://lingulist.de/documents/sequence.pdf">online</ref>] </bibl>
+ <bibl xml:id="rosemann_process_2006">Michael Rosemann / Jan Recker: Context-aware Process
+ Design: Exploring the Extrinsic Drivers for Process Flexibility. In: Proceedings of
+ the Workshops and Doctoral Consortium. Hg. von M. Petit / T. Latour. Belgium 2006,
+ S. 149–158. [<ref target="https://eprints.qut.edu.au/4638">online</ref>]</bibl>
+ <bibl xml:id="seibicke_personennamen_1982">Wilfried Seibicke: Die Personennamen im Deutschen. Berlin
+ u. a. 1982. <ptr type="gbv" cRef="024283177"/></bibl>
+ <bibl xml:id="sitou_requirements_2009">Wassiou Olarewaju Sitou: Requirements-Engineering
+ kontextsensitiver Anwendungen. München u. a. 2009. PDF. [<ref target="http://mediatum.ub.tum.de/doc/679228/document.pdf">online</ref>] </bibl>
+ <bibl xml:id="stoepel_geogen_2021a">Christoph Stöpel (2021a): Geogen v4. In:
+ geogen.stoepel.net. 2005–2021. [<ref target="https://geogen.stoepel.net/legacy.html?">online</ref>] </bibl>
+ <bibl xml:id="stöpel_geogen_2021b">Christoph Stöpel (2021b): Geogen Onlinedienst. Allgemeine
+ Informationen / Häufige Fragen (FAQ). In: legacy.stoepel.net/. 2005–2021. [<ref target="https://legacy.stoepel.net/de/Infos">online</ref>].</bibl>
+ <bibl xml:id="verein_gov_2015">GOV/Webservice. Hg. von Verein für Computergenealogie e. V.
+ In: GenWiki. 2015. Beitrag vom 01.11.2015. [<ref target="https://wiki.genealogy.net/GOV/Webservice">online</ref>]</bibl>
+ <bibl xml:id="verein_gazetteer_2021a">The Historic Gazetteer. Hg. von Verein für
+ Computergenealogie e. V. (2021a) In: Genealogy.net. 2021. [<ref target="http://gov.genealogy.net/search/index">online</ref>]</bibl>
+ <bibl xml:id="verein_index_2021b">Index of /gov/minigov. Hg. von Verein für
+ Computergenealogie e. V. (2021b) In: Genealogy.net. 2021. [<ref target="http://www.genealogy.net/gov/minigov/">online</ref>]</bibl>
+ <bibl xml:id="working-group_neustadt_2021">Neustadt in Europe - Overview. Hg. von Working Group
+ Neustadt in Europa. Overview. In: neustadt-in-europa.de. Neustadt an der Weinstraße
+ 2021. [<ref target="https://www.neustadt-in-europa.de/en/list.html">online</ref>]</bibl>
+ <bibl xml:id="zandhuis_toponyms_2015">Ivo Zandhuis / Menno den Engelse / Edward Mac Gillavry:
+ Dutch Historical Toponyms in the Semantic Web. In: Population Reconstruction.
+ Hg. von Gerrit Bloothooft / Peter Christen / Kees Mandemakers / Marijn
+ Schraagen.Gerrit Bloothooft et al. Cham u. a. 2015, S. 23–41. <ptr type="gbv" cRef="833549804"/>. </bibl>
+ <bibl xml:id="zedlitz_survey_2014">Jesper Zedlitz / Norbert Luttenberger: A Survey on
+ Modelling Historical Administrative Information on the Semantic Web. In:
+ International Journal on Advances in Internet Technology 7 (2014), H. 3/4, S.
+ 218–231. [<ref target="http://www.iariajournals.org/internet_technology/tocv7n34.html">online</ref>]</bibl>
+ <bibl xml:id="zheng_integrating_2019">Yong Zheng / Shephalika Shekhar / Alisha Anna Jose / Sunil
+ Kumar Rai: Integrating context-awareness and multi-criteria decision making in
+ educational learning. In: Proceedings of the 34th ACM/SIGAPP Symposium on Applied
+ Computing. Hg. von Association for Computing Machinery. (SAC '19: 34, Limasol,
+ 08.–12.04.2019) New York, NY 2019, S. 2453–2460. <ptr type="gbv" cRef="1684173736"/> </bibl></listBibl></div>
+ <div type="abbildungsnachweis">
+ <head>Abbildungs- und Tabellenverzeichnis</head>
+ <desc type="graphic" xml:id="abb1"><ref type="graphic" target="#urbanonyme_2020_001">Abb. 1</ref>:
+ Übersicht über Begrifflichkeiten und Zusammenhänge. [Goldberg 2022]</desc>
+
+ <desc type="table" xml:id="tab1"><ref type="intern" target="#tab01">Tab. 1</ref>:
+ Konfusionsmatrix zur Identifizierung von Ortsbezeichnungen in Anlehnung an
+ Fawcett. [Fawcett 2006, S. 862]</desc>
+ <desc type="graphic" xml:id="abb2"><ref type="graphic" target="#urbanonyme_2020_002">Abb. 2</ref>:
+ Relative (links) und absolute (rechts) Verteilung des Nachnamens Hinse.
+ [Goldberg 2022, erstellt mit Geogen Deutschland, Stöpel 2021a]</desc>
+
+ <desc type="graphic" xml:id="abb3"><ref type="graphic" target="#urbanonyme_2020_003">Abb. 3</ref>:
+ Auszug aus einer
 GOV-Abfrage. [Goldberg 2022]</desc>
+
+ <desc type="graphic" xml:id="abb4"><ref type="graphic" target="#urbanonyme_2020_004">Abb. 4</ref>:
+ Auszug einer GEDCOM-Datei. [Goldberg 2022]</desc>
+
+ <desc type="graphic" xml:id="abb5"><ref type="graphic" target="#urbanonyme_2020_005">Abb. 5</ref>:
+ Ermittlung und Bewertung von Kontextdaten, eigene Darstellung als
+ Nassi-Shneiderman-Diagramm. [Goldberg 2022]</desc>
+
+ <desc type="graphic" xml:id="abb6"><ref type="graphic" target="#urbanonyme_2020_006">Abb. 6</ref>:
+ Ortsidentifizierung, eigene Darstellung als Nassi-Shneiderman-Diagramm. [Goldberg
+ 2022]</desc>
+
+ <desc type="graphic" xml:id="abb7"><ref type="graphic" target="#urbanonyme_2020_007">Abb. 7</ref>:
+ Analyse der provinziellen Zuordnung, eigene Darstellung als
+ Nassi-Shneiderman-Diagramm. [Goldberg 2022]</desc>
+
+ <desc type="graphic" xml:id="abb8"><ref type="graphic" target="#urbanonyme_2020_008">Abb. 8</ref>: GOV-Struktur der Stadt
+ <ref target="http://gov.genealogy.net/item/show/object_113700">Wiedenbrück</ref>,
+ Stand: 30. Januar 2021. [Goldberg 2022]</desc>
+
+ <desc type="table" xml:id="tab2"><ref type="intern" target="#tab02">Tab. 2</ref>:
+ Zuordnung von Provinzen zum GOV. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_t2"/></desc>
+
+ <desc type="graphic" xml:id="abb9"><ref type="graphic" target="#urbanonyme_2020_009">Abb. 9</ref>:
+ Aufbau des Programms. [Goldberg 2022]</desc>
+
+ <desc type="graphic" xml:id="abb10"><ref type="graphic" target="#urbanonyme_2020_010">Abb. 10</ref>:
+ Funktionsweise der Main. [Goldberg 2022]</desc>
+
+ <desc type="graphic" xml:id="abb11"><ref type="graphic" target="#urbanonyme_2020_011">Abb. 11</ref>:
+ Funktionsweise der Kontextdatenanalyse. [Goldberg 2022]</desc>
+
+ <desc type="graphic" xml:id="abb12"><ref type="graphic" target="#urbanonyme_2020_012">Abb. 12</ref>:
+ Funktionsweise der Ortssuche. [Goldberg 2022]</desc>
+
+ <desc type="graphic" xml:id="abb13"><ref type="graphic" target="#urbanonyme_2020_013">Abb. 13</ref>:
+ Funktionsweise der Provinzsuche. [Goldberg 2022]</desc>
+
+ <desc type="graphic" xml:id="abb14"><ref type="graphic" target="#urbanonyme_2020_014">Abb. 14</ref>:
+ Anzahl an (Orts-)Clustern nach durchschnittlichem Abstand in km bei Variation des
+ Mindestabstandes zwischen (Orts-)Clustern (10 km, 25 km, 50 km) und Mindestgröße von
+ (Orts-)Clustern (2, 6, und 11), jeweils 200 Bins, Abszisse beschreibt den Abstand in km, Ordinate die Anzahl an (Orts-)Clustern. [Goldberg 2022]</desc>
+
+ <desc type="graphic" xml:id="abb15"><ref type="graphic" target="#urbanonyme_2020_015">Abb. 15</ref>:
+ Zusammenhang zwischen Mindestdistanz, Mindest(orts-)clustergröße und (Orts-)Clusteranzahl,
+ links mit logarithmischer Skalierung. [Goldberg 2022]</desc>
+
+ <desc type="table" xml:id="tab3"><ref type="intern" target="#tab03">Tab. 3</ref>:
+ Vergleich verschiedener Ähnlichkeitsmaße, alle Angaben in Prozent, Grenze: 0,17.
+ [Goldberg 2022]</desc>
+
+ <desc type="table" xml:id="tab4"><ref type="intern" target="#tab04">Tab. 4</ref>:
+ Endzustände des Algorithmus am Beispiel Ortsangaben in GEDCOM-Dateien,
+ Grundgesamtheit von 262.741 Einträgen. [Goldberg 2022]</desc>
+
+ <desc type="table" xml:id="tab5"><ref type="intern" target="#tab05">Tab. 5</ref>:
+ Fehler in der Zuordnung der Provinzen bei der Bezugszeit 1820. [Goldberg
+ 2022]</desc>
+
+ <desc type="table" xml:id="tab6"><ref type="intern" target="#tab06">Tab. 6</ref>:
+ Fehler in der Zuordnung der Provinzen bei der Bezugszeit 2020. [Goldberg
+ 2022]</desc>
+ </div>
+ </div>
+ </body>
+ </text>
+</TEI>