about the deprecation notice about go-whosonfirst-pip-v2

[thisisaaronland]

Of course. It will probably be archived (in the GitHub archive sense of the word) unless that will present an operational problem for people.

[HIRANO-Satoshi]

Thanks!

Why have you started the new one? What's the difference?

Should we move to it? We have some modifications.

[straup]

It is an attempt to de-couple the various components that make up go-whosonfirst-pip-v2 – indexing, storage, querying and serving – in to separate packages in order to allow for more flexibility.

Keep in mind that all of the examples that follow are a) actively being worked b) don't work properly in many cases c) poorly documented still.

For example there is a single "base" package that defines database-agnostic but WOF-specific interfaces for spatial queries and reading properties:

• https://github.com/whosonfirst/go-whosonfirst-spatial

Which are then implemented in full or in part by provider-specific classes. For example, SQLite:

• https://github.com/whosonfirst/go-whosonfirst-spatial-sqlite

This package implements both interfaces which means indexing spatial queries is much faster as are appending "extra" properties (assuming a pre-indexed database generated using the https://github.com/whosonfirst/go-whosonfirst-sqlite-features-index package).

Other packages only implement the spatial interfaces like:

• https://github.com/whosonfirst/go-whosonfirst-spatial-rtree

Or the properties reader interfaces like:

• https://github.com/whosonfirst/go-whosonfirst-spatial-reader

Building on that there are equivalent base packages for "server" implementations, like:

• https://github.com/whosonfirst/go-whosonfirst-spatial-http
• https://github.com/whosonfirst/go-whosonfirst-spatial-grpc

The idea is that all of these pieces can be easily combined in to purpose-fit applications. As a practical matter it's mostly about trying to identify and package the common pieces in to as few lines of code as possible so that they might be combined with an application-specific import statement. For example:

import (
         _ "github.com/whosonfirst/go-whosonfirst-spatial-MY-SPECIFIC-REQUIREMENTS"
)

Here is a concrete example, implementing the PIP service over HTTP using a SQLite backend:

• https://github.com/whosonfirst/go-whosonfirst-spatial-http-sqlite/blob/main/cmd/server/main.go

It is part of the overall goal of:

• Staying out people's database or delivery choices (or needs)
• Supporting as many databases (and delivery (and indexing) choices) as possible
• Not making database B a dependency (in the Go code) in order to use database A, as in not bundling everything in a single mono-repo that becomes bigger and has more requirements over time.

For example:

• https://github.com/whosonfirst/go-whosonfirst-spatial/blob/main/docs/arch.jpg

That's the goal, anyway. I am still working through the implementation details.

Functionally the go-whosonfirst-spatial- packages should be equivalent to go-whosonfirst-pip-v2 as in there won't be any functionality removed. If you have specific needs or modifications you'd like to see I would enjoy hearing about them. This is probably the best place to start that conversation:

• https://github.com/whosonfirst/go-whosonfirst-spatial/issues