-
Notifications
You must be signed in to change notification settings - Fork 155
Proposal: drop support for primitives and geostore and make each parser standalone #268
Comments
i know that the wkt parser and the arcgis parser are both in use. i am also planning on pulling in the primitives and spatial operations into another platform using terraformer. i feel that if we took those away, it would make terraformer unusable. |
i would also support moving terraformer to its own organization (ala koopjs), which would support the additional functionality without completely gutting the module. |
I'm using the spatial operations in Winnow. Very useful for me. It would be nice not to have to instantiate primitives to do the spatial operations so I'd support pulling those out. But I'm not sure how valuable Terraformer is without these things. |
since we assist with conversion to geojson, isn't it as easy as mixing and matching with Turf.js? its my impression that the most heavily used parts of Terraformer have always been the conversion tools. my only intention is to whittle down the surface area of the project to what gets the most use and something that would be more manageable for me to oversee personally (working under the assumption that otherwise it would be more or less unmaintained). i definitely don't want to make any changes that would make the project less useful so i'm happy to receive the feedback. |
i feel that if we moved it to its own organization, and opened up the membership a bit, we'd get a little more traction with maintenance. |
No Turf does not have the same spatial predicates |
@dmfenton i'm glad to hear that terraformer is faster, we spent a lot of time trying to optimize |
I think the best thing to do would be to:
|
i'm ok with (1) and (2), let's discuss (3), and fine with (4). when do we want to move it all into its own org? i'm excited to get this project active again (and have a team that can help). |
Since (3) seems to be the only thing that merits discussion I'll give my stance on it. From an API design standpoint turning JSON objects (GeoJSON) into JavaScript Objects (Terraformer Primitives) is a huge pain like @dmfenton mentioned. The only real benefit is some convenience when calling utility methods like The main cost of Primitives and why I spun the ArcGIS parser out into its own repo is that in browsers using Primitives was simply a lot of extra dependency I didn't use. If anyone is really interested in keeping primitives I am game but I think the core promise of Terraformer should be to work with GeoJSON not its own base object types. So the new |
i finally set up a Terraformer GitHub organization and reserved the My ambitions aren't very grand. I'm mostly just laying groundwork to implement what @patrickarlt suggested back in 2016. to do:
if anyone is interested in chipping in and helping with any of this, the more the merrier! someday: it'd be pretty cool to start porting code from https://github.com/Esri/geometry-api-java one method at a time into I'm on the fence as to whether or not to make the whole thing a lerna monorepo or not. |
I can tackle the wkt parser. will look to see if it still makes sense to stick with jison or move to something else. |
eager to help on this one @jgravois , let me know when/where |
this is what I sent John:
|
good question! my instinct is that it'd make the project the most approachable if each of the three new libraries are entirely standalone. perhaps we can duplicate code initially and then publish a 'helper' dependency in the same org and add it to each bundle? 12/28/2018 edit: the only three i count are
I agree! I don't have any experience including them in CI, but it'd be awesome to incorporate. @JerrySievert I've never been much of a tooling nerd. I like a lot of what we're using in rest-js, but I don't have my heart set on anything in particular. my initial feeling is:
definitely. my plan (as of this morning) is to move this repo into the new org, make it the monorepo, and use new issues here for tracking. if it were me by myself I'd probably lean really heavily on the tooling in https://github.com/esri/arcgis-to-geojson-utils and port it as quickly as possible but if you want to explore something new for the wkt parser I'm a-okay with following your lead in the other two. is all that still clear as mud? if you can't already tell, any suggestions/recommendations/questions or demands will be warmly received. |
today i finally got around to creating a monorepo and porting https://github.com/terraformer-js/terraformer my plan now is to start tracking to do items in the new repo. once we add |
i sat on it awhile, but i finally got around to finishing the port and publishing new packages on npm. @terraformer/spatial <script type='module'>
import { calculateBounds } from 'https://unpkg.com/@terraformer/spatial?module';
calculateBounds({
type: "Point",
coordinates: [ 45, 60 ]
})
// [45, 60, 45, 60]
</script> i got the motivation i needed when someone in the wild cut their own library size in half by swapping in what i'd already finished and shaking the tree. 🌲 given that no one besides me has responded to issues or pull requests in any Terraformer repos in years, i still think that archiving them, directing folks to terraformer-js/terraformer and closing this issue would be the right call. |
at this point it might be a good idea to trim down the scope of Terraformer
proposal
we continue to maintain the repositories below, and refactor them to follow the pattern in arcgis-to-geojson-utils
we deprecate/retire:
we gut the repo here so that it contains only the documentation site for the parsers
what say you @JerrySievert @patrickarlt @ajturner anyone/everyone else?
i would love help, but i'm not the kind of guy to delegate my own proposals
The text was updated successfully, but these errors were encountered: