In practice, how this ends up working is with borough placetypes, where the postal cities code assigns a borough ID to the locality_id parent field.
This is problematic for two reasons:
It causes the resulting locality_gid property returned by the Pelias API to be incorrect
It creates incorrect labels in areas with boroughs, like NYC. An example is a label changing from 132 Dean Street, Brooklyn, New York, NY, USA to 132 Dean Street, Brooklyn, Brooklyn, NY, USA
This change ensures that there can't be any duplicate IDs created in this way, which should solve both the particular problem mentioned here, as well as others we might find in the future.
Our postal cities code originally from https://github.com/pelias/wof-admin-lookup/pull/232 can cause multiple parent IDs to end up the same.
In practice, how this ends up working is with
boroughplacetypes, where the postal cities code assigns aboroughID to thelocality_idparent field.This is problematic for two reasons:
locality_gidproperty returned by the Pelias API to be incorrect132 Dean Street, Brooklyn, New York, NY, USAto132 Dean Street, Brooklyn, Brooklyn, NY, USAThis change ensures that there can't be any duplicate IDs created in this way, which should solve both the particular problem mentioned here, as well as others we might find in the future.