I'm testing out the API right now, but you submit http GET requests (already possible with FG - used it for an ACARS system I made earlier) and it returns an image. I need to be able to display this image as a MapStructure layer.
Actually, it's even easier than that - the ACARS method you used was probably based on the xml-httprequest fgcommand.
Meanwhile, we have native Nasal/HTTP bindings, but even the Canvas system itself supports http:// directly
Thus, it's just a conventional Canvas::Image, just fetched via http - so it should work as expected. In fact, I used the same method for creating this screen shot:
Subject: NavDisplay & MapStructure discussion (previously via PM)Hooray wrote:
So, you can just treat it as a normal raster image and use some helper function/class for assembling proper URLs (including login/passwort) for the current position - and if necessary, also deal with tiling that way. Tom is hoping to implement SQLite-level caching for these purposes, too.
For testing purposes, just adapt a Canvas Image example and use a http:// URL for the file location.
A corresponding MapStructure layer would just be a wrapper around 1) CanvasImage (for raster images) and 2) some customizable URL-building scheme, i.e. a class or function that builds proper URLs
Regarding this particular use-case, it would make sense to provide some form of customizable "post-transform" callback that applies texture mapping (extracting a sub-texture) and transforms the image accordingly.
- Code: Select all
you require a subscription to Wunderground but they let you make 500 requests/day (10/min) for free - so if the users register for their API, we might be able to do this!
For the sake of efficiency, it would make sense to set up a php script that handles the wunderground access and which simply "mirrors" the same API for FG users, so that there's no API keys or redundant requests involved - i.e. VA folks etc would simply use the hosted script instead of directly using the wunderground API - as long as parity with the original API is maintained (same GET request names/arguments), the whole thing can be easily tested and developed in parallel.