|
This is a really specific question, but anyone with experience trying to pull in outside information into a map (live or static) can probably add something to the question. A long winded post is here http://www.thadwester.com/1/post/2012/04/mapping-attainable-bitrates-for-rural-telcommunication.html Does anyone have experience mapping attainable bitrates? OR how were you successful in pulling data from a non GIS source and integrating it into your map. |
|||||
|
|
@Thad, I believe the solution is to write a method to leverage the .Net Process API, which can call command line utilities, submit arguments, and even collect feedback. If you don't want to use .Net, many other techologies allow you to work with Standard In/Out. In Adobe AIR this is accomplished with the NativeProcess API, and in PHP it's handled using the
I'm stressing that the lesson is more accurately one of hardware-to-software interfacing, and not so specifically DSLAM-to-GIS, and you'll accomplish your goal at the architectural level by meshing these technologies together. A Hypothetical Implementation Personally, I'd favor doing this with a C# WebService/Webmethod in the service layer, and a Flex mapping client like OpenScales handling the map presentation (Flex rolls well with streaming data 'cos Flash Player is frame-based). The solution would amount to a client-server implementation where fresh DSLAM data is funneled through the service layer directly into the client. Basically, your map client would constantly listen for fresh data pulses, then update as appropriate. Optionally, though, you could write the client to poll the server for updates in a Timer-based cycle. In either case, you could store the "aging" data in a database and create a widget allowing whomever to click a DSLAM icon and get a "playback" of its metrics over time. In short, your service layer will be responsible for collecting the latest-and-greatest DSLAM metrics in a database, and if the DSLAM is pulsing feedback, relaying that data directly to any client observer. If the DSLAM is not pulsing, it could be polled whenever by a client using a Timer. However, Timers are big heavy thugs, so if the goal can be realized without one, that's the better implementation. As far as the plumbing is concerned, I did something similar to this awhile back to collect real-time GPS information in a Flex map. It was a very similar scenario, except I needed to hit a COM port to get the streaming GPS NMEA sentences. In that case I wrote a tiny .Net terminal application that watched activity on the COM port and relayed any traffic to Standard Out (here's a comparable example). For the presentation layer I created an Adobe AIR client that watched the Standard Out feedback issued by the .Net terminal app. In other words, the client automated the command line interaction, but you never saw a terminal window and I was able to avoid using a Timer because the GPS pulses originated the one-way data stream that went from COM port to a terminal app, to Standard Out, and finally into my AIR app. Reflecting on a Potential Bottleneck I do have to wonder what kind of stress hundreds (thousands?) of DSLAM data streams would put on any server observing them. If I were you, I'd start with a spare/mothballed piece of equipment I could dedicate to the task before I risked exposing a production system to such a battery of streaming feeds. I think stress-testing this sceanario would be deserving of a separate experiment in its own right. I certainly don't have enough server-administration experience to hazard a guess, but I bet you have access to some in-house engineers that could. If you want a primer on applying the Process API, check out this answer I posted a few months ago. That exact example shows calling a Python script using the Process API, but calling a .exe utility, or whatever, won't matter because the plumbing is essentially the same --the point is you'll use the Process API to dispatch calls to and collect feedback from Standard In/Out (which is exactly what I show in that example). By the way I am fully-jealous of this task you have here. You're welcome to drop me a line if you need more details. Bon chance. |
||||
|
|
|
Unfortunately, I have no experience to provide with the first part of your question. That sounds like a conversation that you would have to have with a cell provider or phone company to see if they would be willing to give you a download of their datafiles. Or, you can look for other sources who might have similar information, think federal agencies. It seems like the FCC might have some idea of available bandwidth in various locations. I have no idea what format this might be, but it never hurts to look around. If you manage to come up with something, then that leads to question number 2. If you receive some data, then you first look to see if it has any sort of geographical component. This could be specific x, y coordinates in some system, or it could be a string that has a location encoded into it. Case 1 - Specific coordinates: Figure out what coordinate system they are in, use your favorite GIS software to generate a point layer of those coordinate, and start finding other data to overlay with your points. This may well require you to generate your own custom projection based off an existing one, to allow other layers to overlay properly. Case 2 - Address information related to DSLAM location: Either try to come up with an existing spatial layer containing these locations, or geocode the addresses Case 3 - Encoded spatial information. You will have to review the data to see if there are clues to help you identify the locations. If you can figure these out, then you can again either link the points to an existing layer, or digitize your own point locations to link the table records to. Just remember that any data may have a spatial context. If you can figure out the context, then it is a matter of putting the data into a database table and bringing it into GIS software, and building the spatial data to attach it to. Whatever method you choose, make sure that you have a unique identifier for each record. This will be critical for tying the spatial data back to the attribute data if you have to digitize the records separately. Hope this helps. |
|||||||||||||
|
