Closed mourner closed 9 years ago
@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?
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.
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.
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.
@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/