Roadmap

[ungoldman]

Talked with co-conspirators, here are some ideas that came out of it:

decouple web application from server

• continue API improvements on api.geobin.io repo
• continue client improvements on geobin.io repo

This would allow us to improve and deploy both pieces separately, develop in parallel rather than tightly bundle client and API releases, and more easily modularize and generalize logic for potential separate go/node/whatever mini-projects under geobin-io.

There were other things but I forget them now. @courtf @aranasaurus @jyaganeh please add thoughts, wishes, aspirations. The above is my main wish right now. If that happens methinks tackling issues and deploying small things more regularly would be easier.

[jyaganeh]

Here are some things I'd like to see added to the client once we finish with the decoupling:

• ability to drag or paste data into the browser and have it posted to the api
• return all found geometries as a feature collection or other geojson structure that can be pasted into geojson.io directly

[ungoldman]

@jyaganeh I agree with those things. I think the last thing to do before we can start decoupling is #126.

[ghost]

+1 to pasting data. I have some other ideas:

Important:

• Better handling for overlapping geometries on the map (ie: the popup should allow you to view everything beneath a click).

Less important, but still relevant:

• Being able to select the mapped color for a blob.
• Storing colors/basetile prefs at the bin level on the server, rather than browser level in the client. This makes sharing bins with other people much better because you can control what they see, set up good contrast etc. The browser could still keep track of the most recent settings and apply those to newly created bins.

Not important, but would be cool:

• Selecting shapes already in the map, and getting just that selection out as geojson.
• Drawing new shapes, and getting them back out as geojson. One cool thing about this, beyond a useful editor, is that two people can be viewing the bin, and via websockets, see what the other person is drawing in realtime.

[jyaganeh]

We could use the geojson.io URL API to send our geo data over there for manual editing

[aaronpk]

I think everything from the less important and lower sounds like too much feature creep. I like the idea of pushing out to geojson.io and giving export options for editing and better sharing. Let's not turn this into a collaborative map editor ;-)

The simpler this is, the better. Let's stick to low system requirements (not storing anything permanent on the server) and have it do just one thing that is really easy to explain.

[ghost]

Fair enough, mostly just thinking out loud.

For what it's worth, none of those ideas would add any overhead to system requirements, but I agree it does muddy the site's purpose.

[ungoldman]

I don't think there's any harm in exploring new features once we've addressed the basic issues. Part of the point of decoupling the client app from the API is to allow for this kind of exploration and deviation from the original idea through other sites/services feeding off the API.