On Sun, Mar 13, 2011 at 08:16:00AM -0400, Christopher Schmidt wrote: > On Fri, Mar 11, 2011 at 12:15 AM, Christopher Schmidt > <[email protected]> wrote: > > > Posting access is authed by the OSGeo LDAP server; note that the data in > > this server may still undergo wipes while the code is under development, > > so don't get too attached to it :) > > > > A couple of shortlist items in order to get things a bit more usable: > > > > 1. Adding 'resolution' property to the images and the ability to > > filter on it. > > 2. Cleaning up the currently uploaded data > > 3. Working to upload the remainder of the telascience-hosted > > NAIP data into OAM > > 4. Adding server-side code (and some tools to interact with it) to > > allow for 'mirroring' of any given file, layer, etc. and > > registering the mirrored file with the server; then integrating > > these mirrors into the API in a reasonable way. > > 4) is done, I think. Basically, each image now has a source_url, > which is the 'original' image, and then a 'urls' property, which is > the image and a list of all its mirrors. To mirror an image via the > API, simply post content like: > > POST /api/mirror/ > { > 'image': 2, > 'url': 'http://example.com/mymirror.tif' > }
This functionality was used to add a mirror of the Washington imagery to OpenBaseMap, the map server supported by the CUGOS group, I believe. This means that images like: http://oam.osgeo.org/api/image/1550/ now have multiple URLs: "urls": [ "http://hyperquad.telascience.org/naipsource/Washington/20090801/big_mosaic_4326_c14_r1_jpeg_mask.tif";, "http://oam.openbasemap.org/data_WA_2009/big_mosaic_4326_c14_r1_jpeg_mask.tif"; ], so that even if hyperquad disappears for some reason, the WA NAIP imagery will continue to exist. 3) is also done: this means that OAM now has more than 100,000 images in the index. Unfortunately, this also means that some of the tools which were built around doing things the short/simple way are failing, so more work is needed, especially in performance of querying for larger collections of images and by a bounding box. Attacking the performance problems with a stick is my next big task. In the meantime, you can do limited queries relatively easily: http://oam.osgeo.org/api/image/?bbox=-73.5,41.9,-73.3,42.1 -- an area in the intersection of MA, CT, NY, 1.4s http://oam.osgeo.org/api/image/?layer=25 -- all images in layer 25, all of CT, 5s In the short term, I've stuck a limit 10000 on the /api/image/ so that it doesn't spin out of control. I hope to make progress on: 1. Extending this to support paging in general, so that clients can simply page through all results. -- Okay, went ahead and did this while writing this email. So you can now do: http://oam.osgeo.org/api/image/?start=5&limit=10 and it will return the 5->15th results. More API discussion on what people expect to see in this regard is welcome. There is a max of 10000 on this, and it seems an important step will be to actually include metadata about result set size in the API response, but that can all come a bit later. 2. Figuring out why this is so slow in the first place, and making this hard limit higher eventually. As a quick demo of using the index, you can checkout http://crschmidt.net/mapping/oam-browser?zoom=10&lat=37.01462&lon=-109.05853&layers=BT in a recent Firefox or Safari -- it should show an OL map with an overlay of up to 500 OAM image resources. The demo is limited to 500 images for interactivity. Thanks, -- Christopher Schmidt Web Developer _______________________________________________ talk mailing list [email protected] http://host134.hostmonster.com/mailman/listinfo/talk_openaerialmap.org
