BUG: geonames extractor problems with admin hierarchy

[gklyne]

I just noticed a problem with some data generated by the geonames extractor/converter.

E.g., see: https://github.com/culturesofknowledge/emplaces/blob/master/src/geonamesdataexport/data-20190624/geonames-data-ref-by-EMLO-0001-0100.ttl#L20467

The em:hasRelation showing Friesland_ADM1_2755812_geonames as part of Netherlands_PCLI_2750405_geonames has an incorrect value for em:relationType at line 20496: it is recorded as em:P_PART_OF_A, but should be em:A_PART_OF_A.

At the time of writing, I don't know if this is throughout the data - I suspect it is: I may have failed to take account of the type of the place for which the relation is described.

Code for this is at about:

https://github.com/culturesofknowledge/emplaces/blob/master/src/geonamesdataexport/get_geonames_data.py#L865

It does appear that the relationship type is hard-wired, rather than being derived based on the place type.