You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After #93, we now have much more consistent hierarchy data for Geonames records, but the GIDs are sometimes not correct. As can be seen in the query below, the ID section of the GID is correctly replaced with the Geonames ID, but the source section stays whosonfirst:
The left column is production, without #93, the right is prod_build with #93. Note that the locality_gid field on the right is whosonfirst:locality:3530597: the id section has been updated to 3530597 to match the id of the record, but the source is still whosonfirst.
Update: this may be a bug in pelias/model and pelias/api: see this snippet of code from api
After #93, we now have much more consistent hierarchy data for Geonames records, but the GIDs are sometimes not correct. As can be seen in the query below, the ID section of the GID is correctly replaced with the Geonames ID, but the source section stays
whosonfirst
:http://pelias.github.io/compare/#/v1/search%3Fsources=wof&text=mexico%20city
The left column is production, without #93, the right is prod_build with #93. Note that the
locality_gid
field on the right iswhosonfirst:locality:3530597
: theid
section has been updated to3530597
to match theid
of the record, but the source is stillwhosonfirst
.Update: this may be a bug in pelias/model and pelias/api: see this snippet of code from api
The text was updated successfully, but these errors were encountered: