using wigle.net as a location data source
Hello, I'm involved with geoclue (a geographic information framework for linux) development and I'm trying to find out if wigle.net database would be a suitable data source for us.
Some background: geoclue is a Free Software service/library that usually runs on a mobile computer. It uses several backends to get geographic data from various sources and abstracts the differences of those data sources as much as possible, so applications can just ask for e.g. current coordinates and not care where the coordinates come from (current options for coordinates are GPS and hostip.info).
Back to the business at hand: I'd like to use wigle.net as another position data source. Currently I believe I could technically do it like this:
Some background: geoclue is a Free Software service/library that usually runs on a mobile computer. It uses several backends to get geographic data from various sources and abstracts the differences of those data sources as much as possible, so applications can just ask for e.g. current coordinates and not care where the coordinates come from (current options for coordinates are GPS and hostip.info).
Back to the business at hand: I'd like to use wigle.net as another position data source. Currently I believe I could technically do it like this:
- find out ID of the current access point
- use the unofficial API to get access point data:
Code: Select all
http://wigle.net/gpsopen/gps/GPSDB/confirmquery?netid=00:11:22:33:44:55&simple=true
- parse the result for coordinates
- Is usage like this ok with regards to server/bandwidth usage and the data usage?
- I've read about a possible requirement for authentication for the API. This would unfortunately make wigle.net unusable for us. Do the authentication plans actually cover the usage I described, or would something like this be an exception?
- Anything else I should take into account?
Thanks for the reply, bobzilla.
I can understand that you want to keep the full API (e.g. querying a list of APs at a location) behind authorization, but we, or rather geoclue users, would only be looking for:
EDIT: reading the last paragraph made me realize that I didn't really cover what I intended... My point was that even though the wigle.net API returns more details than HostIP (a significantly more accurate location), the information would only be available to people who already know about the existence of that AP.
This would imply that the answer to my second question is that a wigle.net account will be required for all uses in the future. Unfortunately that will mean that in practice we can't use wigle.net as a data source. This decision is naturally within your rights, but... could I ask you to reconsider this?Whatever you do is fine as long as you follow the eula. If you have people create accounts and login to do queries, that'd be fine. Using one login to re-vend data isn't, however.
I can understand that you want to keep the full API (e.g. querying a list of APs at a location) behind authorization, but we, or rather geoclue users, would only be looking for:
- one item of data at a time
- lat/lon coordinates of the netid that we know already
EDIT: reading the last paragraph made me realize that I didn't really cover what I intended... My point was that even though the wigle.net API returns more details than HostIP (a significantly more accurate location), the information would only be available to people who already know about the existence of that AP.
I guess the silence means positioning using wigle.net (without logging in) is out of the question then. Not that bobzilla wasn't clear about that that in his answer...
I really think that an open MAC address location database would be a very, very useful idea (especially as mobile device popularity seems to grow). Looks like someone has to setup another project that gathers the same data then... Real shame,
I really think that an open MAC address location database would be a very, very useful idea (especially as mobile device popularity seems to grow). Looks like someone has to setup another project that gathers the same data then... Real shame,
The core issue has not changed, you need a wigle account to use the data, and be bound by the eula.
There a number of projects/people historically who have wanted to offer things like this just have users log in to use the wigledata in their app/whatnot. Keeping in mind the usual caveats about its-really-not-an-API. (yet!)
People have operated other sites in parallel to wigle in the past, and i'm sure they will in the future. I'd have to say: its a fun and very challenging problem set.
There a number of projects/people historically who have wanted to offer things like this just have users log in to use the wigledata in their app/whatnot. Keeping in mind the usual caveats about its-really-not-an-API. (yet!)
People have operated other sites in parallel to wigle in the past, and i'm sure they will in the future. I'd have to say: its a fun and very challenging problem set.
The reason I posted twice even after getting this answer was because I couldn't figure out the point (as in why require the EULA)... but having thought of it, I'm guessing there's the financial side: the DB must be pretty valuable to some companies in the field. I can fully understand you'd want to keep it that way.The core issue has not changed, you need a wigle account to use the data, and be bound by the eula.
You can probably understand that for a geoinformation library this is not a very reasonable alternative... but no worries, we'll just go on our separate ways then. Good luck to Wigle, and thanks for responding.There a number of projects/people historically who have wanted to offer things like this just have users log in to use the wigledata in their app/whatnot.
abuse prevention is the singlemost important reason. a fact that rears its ugly head as soon as you put together anything of this nature, sadly. one of the sad side effects of online anything these days.The reason I posted twice even after getting this answer was because I couldn't figure out the point (as in why require the EULA)...
signing in to online services is hardly a shift from past behavior. but i suspect i understand your motivations (which are endemic to folks who haven't looked into the problem), so good luck! we'll be here :-)You can probably understand that for a geoinformation library this is not a very reasonable alternative...
Thanks for explaining, uhtu
That's interesting. Can you elaborate on that? I've been trying to think what that might mean (in context of read-only access), but can't guess what it is...abuse prevention is the singlemost important reason
Harvesting and revending the dataset, doing exorbiant amounts of queries, taking up bandwith above and beyond reasonable access... That was the first three items that came to my mind. But then ofcourse I must be better at guessing than you.Thanks for explaining, uhtuThat's interesting. Can you elaborate on that? I've been trying to think what that might mean (in context of read-only access), but can't guess what it is...abuse prevention is the singlemost important reason
Dutch
I guess there is a possibility to purchase the data from Wigle for this use. I know some users have checked off out box allowing WiGLE to sell the data.
While the check book is out, this "Twine Ball" would make an interesting purchase as well.I guess there is a possibility to purchase the data from Wigle for this use.
At wardrivers.be i have a function to get te coördinates of a specific mac adress, we use it for calculation rangeplots.
When you are on top of a building, we use a 28dbi antenna to find ap's, then we compare it to the database which gives a file that can be imported in mappoint.
Now we can se the potential of a node location before installing a wireless-belgium node.
When you are on top of a building, we use a 28dbi antenna to find ap's, then we compare it to the database which gives a file that can be imported in mappoint.
Now we can se the potential of a node location before installing a wireless-belgium node.
Return to “WiGLE Project Suggestions”
Who is online
Users browsing this forum: Ahrefs [Bot], Google [Bot] and 2 guests