Create a back end script that exports all needed images for a crag guide

[brendanheywood]

Possibly given params to specify what sizes of images to export

[brendanheywood]

eg extractImages.pl [cragId] [sizes]

extractImages.pl 8040888 smallcropped medium large

It should extract all topo images and any 'good' photos (do we have something like this already?)

[scd]

I have made web service call which streams a zip file (in repo ready for testing).

/zip/mobileimages/NODEID or /zip/mobileimages/NODEID/PUBLISHERID

with parameters: td: topo dimension, can be set multiple times pd: photo dimension, can be set multiple times

http://27.32.153.207:8080/zip/mobileimages/8040888?td=fixedwidthsmall&pd=croppedsmall

It returns a flat zip file of requested images with the following filename format

• topo-TOPOID-DIM.jpg
• photo-NODEID-PHOTOID-DIM-QUALITYTAG.jpg The QUALITYTAG is a, b or c which corresponds to campbells photo assessment. If a node has at least one A Grade photo then all A Grade photos for that node are include, otherwise B Grade, otherwise C Grade.

Have a play and let me know if it is what you want.

I'm suspicious that the compression is not working properly for the Archive::Zip perl module (or I've done something wrong), but I wanted to get it out there for you to test.

If you want just thecrag content the call without publisher. If you want publisher content the call with publisher id. You might want both for a particular area, which will require two calls???

I've done some neat streaming in the perl code so the thing does'nt take up internal memory when created. If you want to have a look refer to MyApache2::Zip.

[brendanheywood]

This url/api looks like a great start:

1) however it doesn't work, just pulled, deployed, restarted

2) with the publisher id, I'd like to use it as a preference, eg use it if it exists but fall back to the community content if it doesn't. Maybe I can show both sets in the iphone somehow and then we wouldn't need this.

3) how much work is it to have the same directory structure as the static dir? This would it much easier to swap between them seamlessly.

The compression isn't too much of an issue for now. This is a build tool more than a live api

[scd]

Now try it, I needed to reconfigure apache after your install.

I'm happy to do the publisher any which way you want. I would have thought that keeping it the way we have it now would give you slightly more flexibility as there may be cases where you just want publisher data. What about an additional parameter - a flag which told the service to get both the community and publisher info - it would save a second service call?

I'm not sure how the internals of your app works. If better as a directory structure then we can do it that way. I sort of assumed a simple lookup on the topoID might be easier, that is the reason why I did it that way. What would your directory structure look like RootID/Level1NodeID/Level2NodeID/.../TopoID???

[brendanheywood]

Sweet, the zip is working.

On the publisher front, I'm already getting all available beta's. I'm thinking it's probably better if I show both in the app, but I'll polish the display a bit so they aren't duplicated.

Also I've just realised were talking about slightly different things - I was talking about the duplicated beta fields, but in your context it's photos. Either way I'll grab the lot and put more logic into the app to match the website.

At the moment all images are sourced directly from the live website, so swapping over to internal images is just changing a static prefix. When we get into a more mixed, half live half synced app it will make it a lot easier having the photos on the iphone disc essentially as a persistent cache of the live site.

So the directory structure will be an perfect subset / slice of the static dir.

[scd]

So you want me to change to a directory structure using the nodeIDs?

[brendanheywood]

Yeah so match the existing static dir exactly

eg:

/photo/00001/fixedheightbigthumbnail/25133284.jpg

NOT: RootID/Level1NodeID/Level2NodeID/.../TopoID???

[scd]

Ok, now that makes sense. I've been in bed sick the second half of yesterday and most of today and only been venturing out to read my emails and do little things. Point is I'm working on limit mental capacity.

But there is some logic missing from the api. How do we know which photo is associated with which node. If a climb has multiple photos then the api will only ever give one random photo, so your app won't know about the other photos.

Also if we are only ziping the 'good' photos then there is a possibility that the api references a photo that has not been zipped.

The topos will definitely work with this directory structure because the api lists all the topos.

[scd]

The new zip is based on the static directory, and it includes all photos not just the 'good' ones.

If we need to select the good ones this will be another api call???

it's in the repo

[brendanheywood]

If later we do want to filter them I'd add it as a new param not a separate call, but for now I think we're good

[brendanheywood]

ah sorry - the crag guide api only shows one pic randomly. I'll just work with this and evolve it as needed. At the moment the critical stuff is the topos anyway. If we want instead of one random photo we could show the top n photos, or the most recent n photos and mirror this in the web site as well which I think we also discussed.