Use live data instead of flat files.

[ghost]

• Put existing flat file into OpenStreetMap.

  id => node:id
  title => tag:name
  longitude => node:lon
  latitude => node:lat
  location => ? (may no longer have relevance)
  artists => tag:artist_name
  url => tag:source
  imageurl => tag:website_1
  fullimage => tag:website
  description => tag:note, tag:note_1 if more required.

• Use query-overpass npm module to load nodes from OSM and return base data in a format the client expects.

• Stand up a MongoDB image store with GridFS, using the following structure.

  {node, thumbnail, image}

• Include instructions on getting the MongoDB instance running and working with the proxy.

• Include an images route for both the client and OSM to send users for images and thumbnails.

  GET /images/node: returns an image with the appropriate MIME type.
  POST /images: creates a thumbnail and places the image in the GridFS store.

• Get OAuth working for the proxy using the iArtNorfolk OSM account.

• Define a GET /exhibits/id, which returns an exhibit from OSM and the associated image and thumbnail from GET /images/id.

• Define a POST /exhibits route, which creates an exhibit in OSM. Calls POST /images to place an image there as well.

[wbprice]

For the images route, what about:

GET /exhibits/{id}/images // returns an image (array of images) for exhibit {id}
PUT /exhibits/{id}/images // route to post an image to exhibit {id}

seems simpler to me.

[ghost]

Resource for Ember.js REST Adapter.

[qwo]

i think i felt blocked when we had to write it as a service that integrates with localwiki and hosts data also on OSM which made it feel bloated. Re: OHI is 4 different repos, hrt-bus spans 3, writing smaller services distinct services make sense.

To unblock, I like you guys are just going with rolling your own API. Im thinking if any of those ^ priorities arise again we should just write separate integrations to port data back and forth and keep the architecture modular.

anyway +1 feel free also to blow away the code especially with the express->hapi transition and put this on a branch

[wbprice]

Re: item 1; I had hoped to build a tool that would import the flat file automatically to OSM, but it appears that the climate within the OSM community is chilly towards importing a lot of data all at once (especially as a first contribution). We should look at having a mini mapathon to add all the nodes to OSM manually.

[ghost]

Absolutely. I could also probably do this during breaks at work, honestly.

[jonahadkins]

im on it -- 👍

[ghost]

😃 Sweet man, thanks.

[wbprice]

Exhibits route is implemented here:

http://localartapi-code4hr.rhcloud.com/exhibits
http://localartapi-code4hr.rhcloud.com/exhibits?bbox=36.75,-76.44,36.98,-76.13

[ghost]

@wbprice, does the bounding box work here?

[wbprice]

Yes. If you don't send a bounding box to the /exhibits route it will assume bbox=36.75,-76.44,36.98,-76.13, but you specify a larger or smaller box as you need to.

[ghost]

Wow, awesome, man!

Also, I just went through and updated the descriptions and fullimages in each OSM node, then committed the OpenShift URL to our repo. Once we can correct some style things with images on the front page, we should push that to production.

[qwo]

i think this has been implemented

[ghost]

We still have 5/7 subtasks that we have not implemented, this is not closed yet.