Skip to content

Catch warning from unsupported hierarchy entries - #149

Open
orangejulius wants to merge 1 commit into
masterfrom
fix-hierarchy-errors
Open

Catch warning from unsupported hierarchy entries#149
orangejulius wants to merge 1 commit into
masterfrom
fix-hierarchy-errors

Conversation

@orangejulius

Copy link
Copy Markdown
Member

During an import I noticed an error like the following:

error TypeError: Cannot read properties of undefined (reading 'name')
  at /code/import/source/whosonfirst/map/hierarchies.js:26:62
  at Array.forEach (<anonymous>)
  at Object.mapper [as hierarchies] (/code/import/source/whosonfirst/map/hierarchies.js:24:15)
  at mapper (/code/import/source/whosonfirst/map/place.js:39:7)
  at DestroyableTransform._transform (/code/import/mapperStream.js:7:21)
  at Transform._read (/code/node_modules/through2/node_modules/readable-stream/lib/_stream_transform.js:166:10)
  at Transform._write (/code/node_modules/through2/node_modules/readable-stream/lib/_stream_transform.js:155:83)
  at doWrite (/code/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:390:139)
  at writeOrBuffer (/code/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:381:5)
  at Writable.write (/code/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:302:11)

After some investigation these errors don't appar to be hurting anything, they happen when a record in a layer we don't currently support is imported. In this case it was the postalregion layer.

We could consider supporting that layer in the future, which I think is also easy, but in the meantime we should at least silence these errors.

During an import I noticed an error like the following:

    error TypeError: Cannot read properties of undefined (reading 'name')
      at /code/import/source/whosonfirst/map/hierarchies.js:26:62
      at Array.forEach (<anonymous>)
      at Object.mapper [as hierarchies] (/code/import/source/whosonfirst/map/hierarchies.js:24:15)
      at mapper (/code/import/source/whosonfirst/map/place.js:39:7)
      at DestroyableTransform._transform (/code/import/mapperStream.js:7:21)
      at Transform._read (/code/node_modules/through2/node_modules/readable-stream/lib/_stream_transform.js:166:10)
      at Transform._write (/code/node_modules/through2/node_modules/readable-stream/lib/_stream_transform.js:155:83)
      at doWrite (/code/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:390:139)
      at writeOrBuffer (/code/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:381:5)
      at Writable.write (/code/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:302:11)

After some investigation these errors don't appar to be hurting
anything, they happen when a record in a layer we don't currently
support is imported. In this case it was the `postalregion` layer.

We could consider supporting that layer in the future, which I think is
also easy, but in the meantime we should at least silence these errors.
@orangejulius orangejulius changed the title fix(import): Catch warning from unsupported hierarchy entries Catch warning from unsupported hierarchy entries Aug 5, 2026

@missinglink missinglink left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch.

I like the idea of not necessarily silencing the warnings but at least catching them and handling them more gracefully.

One potential issue with this is that I just merged this PR which introduced the concept of the ontology.type not exactly matching the placetype (or equivalent).

As such this change could potentially become brittle to failure if that ontology mapping concept became more widespread, and particularly if we decided to adopt an ontology not directly mirroring WOF.

That said, I'm fine with this for now if we don't want to over-think it.

Alternatively I'd also be fine with checking $pt and bailing with a warning.

@missinglink

missinglink commented Aug 18, 2026

Copy link
Copy Markdown
Member

Worth noting that, in theory, the WOF spec should contain all valid entries (such as postalregion) however that doesn't seem to be the case. I've also flagged others in the past, I think it's just not up-to-date.

@missinglink

Copy link
Copy Markdown
Member

I ran the update script in import/source/whosonfirst/config and it seems to have updated the config to include the latest additions to the WOF placetypes.

jq -r 'to_entries[] | "\(.key): \(.value.name)"' import/source/whosonfirst/config/placetypes-spec-latest.json | grep post
470996387: postalcode
1897483759: postalregion

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants