Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

flatgeobuf support #34

Open
gertcuykens opened this issue Jul 27, 2019 · 6 comments
Open

flatgeobuf support #34

gertcuykens opened this issue Jul 27, 2019 · 6 comments

Comments

@gertcuykens
Copy link

Because in my opinion you are the king of osm and geojson in golang :P would appreciate your take on flatgeobuf as a replacement of geojson

see: flatgeobuf/flatgeobuf#7
see: mapbox/tippecanoe#777

@paulmach
Copy link
Owner

more specifically, do you mean geojson <-> flatgeobuf?

@gertcuykens
Copy link
Author

gertcuykens commented Sep 17, 2019

Maybe have a look at the format, if you can spot improvements. I think the geo community need desperately a format for heavy lifting and streaming geo data. Geojson and xml are just to verbose. Just trying to convince as many people as possible to agree on a design so we have global tool support for a more performant intermediate format. Others will probably implement it for you and and do a pull request for it in orb/encoding But everybody needs to agree on some format first. For example topojson is other candidate I already did a pull request for #33
Thanks

@paulmach
Copy link
Owner

I looked at flatgeobuf but don't see much documentation. I see a few lines for Specification in the readme and some flatbuffer files. I don't really understand how to pack geometry into them. It seems like you'd need byte compatible implementations of geobuf and flatbush in golang too.

As for topojson. Thank you, I'll take a look.

@bjornharrtell
Copy link

@paulmach flatgeobuf is now more mature than last year and integrated in several well known GIS software. golang support is still lacking but note that geobuf is not a dependency it's just inspired by it and flatbush is not a strict requirement. If you are interested I will take a second look at providing a reference golang implementation (even though I've very rarely touched golang).

@morandd
Copy link

morandd commented Oct 18, 2022

FlatGeoBuf support in Go would be amazing.

In the meantime, Shapefile and GeoPackage seem like the only binary formats which are supported both by Golang and by GDAL

Geobuf format, as provided in this package as well as by the "spatial-go" package, was a nice binary format (and considerably more compact than FlatGeoBuf in my experience), but Geobuf seems to be no longer actively maintained by Mapbox, and the format is not supported by GDAL, so that seems to be a dead end.

@vcschapp
Copy link

vcschapp commented Jan 5, 2024

For folks who are interested, I've implemented what I think is a very good low-to-medium level native Go library for FlatGeobuf: https://github.com/gogama/flatgeobuf. I'd love to hear feedback if anyone has some!

The difficulty I've observed with FGB at least in Go is that although it is wonderful to be able to read and write the lower-level FlatBuffer data types and search the index (all of which my library does quite cleanly, I think), there is still a lot of tricky manual boilerplate required to unpack the FlatBuffer tables and feature properties into high-level structured types that people are used to coding against, for example org.Geometry.

I'm working on a higher-level library to solve this problem: https://github.com/gogama/flatgeobuf-convert. It's in a pretty early stage, but I imagine within 30-60 days I'll have an alpha version available that lets you pack/unpack between Orb types and FlatGeobuf low-level types and handle features properties more cleanly also.

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

No branches or pull requests

5 participants