On Aug 17, 2010, at 2:57 PM, Andy Allan wrote:
> On Tue, Aug 17, 2010 at 9:06 PM, Michal Migurski <m...@stamen.com> wrote:
>
>> I'm super flexible. Walking Papers is currently licensed under the GPL, so
>> you won't have any license issues that I'm aware of. I used external
>> libraries like Smarty (http://www.smarty.net), PEAR (http://pear.php.net),
>> NumPy (http://numpy.scipy.org), PIL
>> (http://www.pythonware.com/products/pil), and VLFeat (http://www.vlfeat.org).
>>
>> The REST API is currently read-only: you can get information about prints
>> and scans and so on for use in OSM editors, but I'm imagining adding ways of
>> writing data to the site as well. I'm basically completely happy to do
>> whatever work is necessary to make the project interoperable with other
>> codebases.
>
>>
> From my previous work with WP, I'd say the upload API is a weak point.
> Being able to post directly to an endpoint, rather than being required
> to pull a form in order to get the secret, would be an instant bonus.
> Similar things would be of benefit to the decoder daemons too, which
> also have to get html pages and then parse them for the required
> tokens. When I wrote some invalid html in a footer it took me a long
> time to realise that was what was causing poll.py to crash!
Great suggestions, thanks. I had this whole idea that the XHTML content of the
pages itself constitutes an API, but I'm starting to see that the confusion for
developers here is a problem. I can improve the polling script to use a more
forgiving parser like BeautifulSoup as a stopgap, for example.
The nice thing about the form is that it allows WP to have two upload
behaviors: Amazon S3 or local files. I'm not sure how to square the request
signatures of S3 with the form upload business, but most consumers (e.g. people
using web browsers) will already have a form-parsing client on their end.
> We've discussed briefly before, but I'd also like to see WP scan
> endpoints not relying on the print endpoints being active (since they
> make a call to the print ID url to find the scan locations). That
> means that people would then be able to set up custom WP print
> generators (say with their own data overlays, on an internal machine)
> and the resulting printouts would work on any WP scanning endpoint.
I've got some work toward this goal on a branch, mostly consisting of adding a
bbox to the URL in the QR code and increasing the print dimensions of the code
to account for the consequently higher resolution. If the request doesn't
return a status=200, a look at the bounds in the URL should be enough to do a
complete scan.
> Back to the OSM integration, the first step would be to integrate an
> option to print a WP print. The joy of git branches being we can code
> a button on the front page and leave the decision until later. From
> the WP end, the print generation API is quite dependant on the aspect
> ratio of the preview map. It would be great if WP could accept a
> lat+lon+zoom+paper combo and figure out the corners for itself.
Very true, I'll see what I can do here. Shouldn't be overcomplicated.
> Finally, if there are unicorns on offer then mine would be in the
> shape of a KML overlay on the prints!
Can you explain more about this?
-mike.
----------------------------------------------------------------
michal migurski- m...@stamen.com
415.558.1610
_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
