Use v3 as a library

[wieringen]

I was using the writer interface of v2 combined with github.com/paulmach/orb to create my pmtiles file.

	writer := pmtiles.NewWriter("./base.pmtiles")
	for z := minZoom; z <= maxZoom; z++ {
		covering := tilecover.Bound(bound, z)
		for tile := range covering {
		    layers := mvt.Layers{.....layers.....}
		    tileData, _ := mvt.Marshal(layers)
    
		    writer.WriteTile(
			    pmtiles.Zxy{
				    Z: uint8(tile.Z),
				    X: tile.X,
				    Y: tile.Y,
			    },
			    tileData,
		    )
		}
	}

	metadata, err := json.Marshal(pmtiles.Metadata{
           ...metadata...
         })
	if err != nil {
		return err
	}
	writer.Finalize(metadata)

Is something similar still possible using v3?

To create a better separation of concerns, it might be a good idea to split the pmtiles folder. The pmtiles folder can hold all the library code for reading and writing pmtiles. Next to a cmd folder that can hold the cli related commands and logic for handling flags, etc.

[bdon]

Yes, at some point I was planning on making that separation like you suggested. Does your use case need deduplication and compression or not? We may need to expose multiple writer interfaces: the simplest one would be "dumb" which assumes the data you are passing in is already compressed.

[bdon]

What about splitting into two folders, one called cmd and one called util (or lib ?) that handles low-level serialization, has a Writer interface, etc

I'd like to rename from pmtiles as that is the new preferred name of the compiled executable (instead of go-pmtiles)

[wieringen]

A common pattern I see a lot is something like this: https://github.com/golang-standards/project-layout
Examples:

• https://github.com/kubernetes/kubernetes/tree/master/cmd,
• https://github.com/influxdata/influxdb/tree/master/cmd

So in your case, that would be something like this:

cmd/pmtiles/app/*.go // Hold cli commands, parsing flags, uploading to bucket, converting, serving etc. Leverages pkg/pmtiles for core functionality.
cmd/pmtiles/main.go // cli entry point.
pkg/pmtiles // Lib that exposes a normal writer/reader interface, and handles reading, writing, compressing, and deduplication.

Having the same name for both the lib and the cli is not a problem (in my opinion), both are valid entry points. An alternative might be dropping the pkg dir and using encoding/pmtiles? It's similar to what orb is doing (https://github.com/paulmach/orb/tree/master/encoding/mvt) and the std lib (https://pkg.go.dev/encoding/json).

orb can gzip the mvt tileData, it exposes both a Marshal and MarshalGzipped method. Not sure how and if it supports deduplication.

[bdon]

seems like https://github.com/alecthomas/kong or https://github.com/spf13/cobra are the preferred way to structure CLI applications, any opinion on either? #26

[wipfli]

Having go-pmtiles as a library could also be useful in the future for example for a MapLibre GL Native app which allows you to download a pmtiles extract and save the map data on your mobile device. The area downloads would require something like #31...

[tyrauber]

MapLibre GL Native app which allows you to download a pmtiles extract and save the map data on your mobile device.

@wipfli, very happy to see you helping out here! We, @TheOutbound, would very much like to see this happen.

[bdon]

As of 1.14 there is now a more reasonable interface to package methods outlined here:

https://pkg.go.dev/github.com/protomaps/go-pmtiles@v1.14.0

closing this as a duplicate of #46 - we should still evolve the internal cmd/package structure