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

Ditch TopoJSON support? #43

Closed
mourner opened this issue Mar 25, 2015 · 5 comments
Closed

Ditch TopoJSON support? #43

mourner opened this issue Mar 25, 2015 · 5 comments

Comments

@mourner
Copy link
Member

mourner commented Mar 25, 2015

@mourner: I also had some thoughts about whether I made a mistake by pushing TopoJSON support instead of keeping things simple and limited to GeoJSON
The size compression benefits are good but it makes the format significantly more complex, this will harm adoption rate
well, not very complex currently, but it'll be much more complex when we make it streamable
@tmcw: hm, i think yes, we should dump it.
i'm divided on topojson because of the dual purpose of topology in it
like, a really good open source implementation of a topology-supporting geometry system... super useful
but topojson is mainly doing it to save bytes

@brendan-ward
Copy link

@mourner What about a separate implementation for topojson instead? Seems like both benefit from the building blocks established here, but both geometry systems don't need to realized in the same container... Could be a separate project in a separate repo if needed for better isolation.

Would having separate implementations help reduce the complexity of each to a tolerable level? Or put differently, is the aggregate complexity of doing both here in the same container higher than the sum of the complexities of doing each individually?

@mourner
Copy link
Member Author

mourner commented Mar 26, 2015

Separate repo may be a good option, since the two repos could be developed at a different pace then, while we could focus on perfecting an awesome + simple GeoJSON compression that has higher chances of adoption.

@mourner
Copy link
Member Author

mourner commented Mar 27, 2015

Removed and feeling pretty good about it — makes iterating on the spec so much easier, and simpler is pretty much always better. Topobuf would be a good name for a project this branches out into. I also think that sum of complexities of two different projects will be lower than trying to squash two pretty different formats into one spec.

@ramsestom
Copy link

So is anyone currently developping a "Topobuf" project? It looks like no one is maintaining a .proto file for topojson since it has been ditched here, which is sad.

@maurizi
Copy link

maurizi commented Feb 18, 2022

@ramsestom I needed it myself for a project, so I've forked the 1.0 version of this library with geojson support removed.

It's on npm as topobuf and hosted on Github https://github.com/azavea/topobuf/

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

4 participants