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
borough
placetypes, where the postal cities code assigns aborough
ID to thelocality_id
parent field.This is problematic for two reasons:
locality_gid
property returned by the Pelias API to be incorrect132 Dean Street, Brooklyn, New York, NY, USA
to132 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.