Andrzej/Jorge, This is good to hear. There have been large group discussions involving developers who don't have time to take the project on.
So if there was some sort of general specification you'd be interested in helping? -Kate On Fri, Jul 16, 2010 at 2:19 PM, andrzej zaborowski <balr...@gmail.com> wrote: > Hi, > > On 16 July 2010 10:34, j artieda <jarti...@yahoo.com> wrote: >> There are any specification or objectives for the software? > > That was also my first question when reading Kate's message. A > platform for serving the imagery similar to the old OAM probably is > not very difficult to make. Making it would require some sample layer > and the hardware in place and I can't imagine the project lacking > community developers. > > Now serving is just half of the OAM service, the other half is the > platform for submitting new data and its metadata. Making it may be > complex to very complex depending on how ambitious you are. Also last > I heard there were several ideas to improve the serving half to be > something much more powerful than old OAM (these are some things I saw > discussed, there may have been many more that I didn't hear): > > * choice between showing the most recent / highest resolution / > highest colour range? / license / tags / more complex criteria?.. > layer on top where many sources are available. For example nearmeap > lets you browse layers either by time of when imagery was taken or the > direction from which the camera was looking at the area currently in > view, since it's rarely exactly 90 deg. This whole thing may be > complex but seems an interesting task. > > * distributed serving. Seems like low priority (since currently > there's just going to be the one server) and low complexity, though > again depends on how ambitious you want to be, there may be some > interesting ideas to get even better performance. > > For the submission part (other people's ideas may be completely > different) I can see the following elements: user registeration (the > normal thing), a submission form for new imagery with option to upload > data right through the web for limited size imagery (local files > upload, give url, give wms url) or get in contact with some > representative to send through traditional mail for example, different > image formats, metadata entry (date, resolutions, projection, camera > angle, colour range, license, cloud cover, tags, ...), an interface to > track the progress of the import of your submitted imagery, e.g. if > you gave a wms url for OAM to mirror or to proxy so you could see how > much was imported and how much cached in each of the formats / > projections. Edit history browsing, possibly rss. Possibly a way for > submitters to indicate how often their source (FTP, WMS) updates with > new imagery so that OAM automatically redownloads / invalidates cache. > > I don't know if this is anything like what other people have been > thinking but this is the kind of specification I'd like to see as a > programmer. Instead the discussions so far have been very high level > that I've seen. I'd also intentionally want to leave out > implementation details from the specification, like what > reprojection/tiling/image-format libraries to use, whether the thing > should be an AWS image or use some other platform or just run on > typical unix distros, whether web front end should use django or > joomla, what caching strategy to use. These things are best tackled > by programmers when they get there and not earlier. > > Cheers > _______________________________________________ talk mailing list t...@host134.hostmonster.com http://host134.hostmonster.com/mailman/listinfo/talk_openaerialmap.org
