Make Search Results Spit out KML (for Google Earth)

[Dutch]

is whose?
wigle hasn't released one because we haven't. that's all.

Dammit!!.. Who are you, and what are you doing posting from uhtu's account.
That reply wasn't in the least ambiguous, and totally out of style for uhtu.
No humour in it, totally clear and not open for interpretation.

<cue twilightzone_theme.mp3>
I think uhtu has been abducted and replaced by a political correct clone. It must either be a TLA or the illuminatii at work here...
</cue twilightzone_theme.mp3>

Dutch

[uhtu]

move along folks. nothing to see here.

do not adjust the foil, it is working properly.. yes you are totally safe from the alien government android control satellites..

perfectly safe.
an API with kxml, wsdl, CORBA, DCOM, RMI, REST,and monkey bindings is riiiiight around the corner. and it will have salted nuts for all!

-_-

[morty]

Hi there!
KML 2.1 has some neat features. It is possible to load Data dependent on your position and zoom-level. This makes it possible to load just the APs you a currently looking at and a maximum of let's say 50.
So here are two Ideas:

• *Build a wigle to kml proxy. Best written in POSIX wich you have to start with user and pass and is being connected via kml and converts wigle-Data to kml.
  *Host the converter at wigle (in case the admins are all right with this ). You'll have to download a kml. Add your user & pass to the url in the KML. And everthing is fine.

What do you think?

[bird603568]

heres a script that i moded that does this http://www.personal.psu.edu/rlr5018/ge/wigle-to-php.txt just change it to .php and keep the icons on the same dir as the script

[morty]

@bird:
Hmm that's not what I ment. I wanted GoogleEarth to connect to wigle (ie via proxy). So I don't need to download the data fist and save it to disk. This is especially interesting as I am from Germany and downloading data is quite complicated. I was thinking about somthing where you just start GE, open a kml and can browse all the wigle-date worldwide.

P.s: I'm looking for something like this: http://earth.kismac.de/

[rasqual]

Since there are reassurances that this is forthcoming, I've assumed a posture of patience. Yes, it's a no brainer. Yes, it's easy to do. Yes, it's elegant, powerful, and the way everything's going. Yes, GE is likely to be the universal geo-app for some time to come. So I presume that wigle's maintainers are working hard to implement something tres cool. That anticipation lets me relax and wait.

[Dutch]

Since there are reassurances that this is forthcoming, I've assumed a posture of patience. Yes, it's a no brainer. Yes, it's easy to do. Yes, it's elegant, powerful, and the way everything's going. Yes, GE is likely to be the universal geo-app for some time to come. So I presume that wigle's maintainers are working hard to implement something tres cool. That anticipation lets me relax and wait.

Me, I'll just watch arkasha eat some more kittens while I'm waiting for : The Wigle-G.E. A.P.I., peace in the Middle East, and the skating season to start at zipcode 666. We all know that good things comes in threes, so those three events will happen concurrently...



Dutch

[mokum]

P.s: I'm looking for something like this: http://earth.kismac.de/

Wow, that is kick ass indeed. That reminds me to upload my kismet to .kismet more often. Thanks.

Cheers,
mokum

[rasqual]

OK, the only KML/Z I find so far, is no longer downloadable.

It's a bit hard to believe that no one has done this yet. Everyone seems to be converting static files instead of creating dynamic bounding box data links.

Is any use of this project in Google Earth dead? I mean, what with 3D interfaces, ray-traced and textured buildings, a growing repository of data, incorporation of time/date information and history animation, Google Earth is a defunct application hardly worthy of use for presenting this huge and growing corpus of data, right?

[themacuser]

I've got a Python app to do this that runs client-side, and uses your wigle login to query. AFAIK, this doesn't violate the EULA, as it runs on the user's machine, and requires them to type their wigle username/password into it to get the login cookie to authenticate the search.

Should I release it?

Oh, and it's coded to the API.

Edit: I already released it a while ago. Here's a link to it. http://x9.ath.cx/python/getAPLocation_v4.py

It lets you query a SSID or BSSID, I could make it work for a location. Maybe even a webserver to point Google Earth's network link on (but running on localhost, of course).

[Tech^CF]

Would be nice if the data could be implemented in Google Earth like Wikipedia and those photography sites. Have anyone @ Wigle been in contact with Google?

[rasqual]

It lets you query a SSID or BSSID, I could make it work for a location. Maybe even a webserver to point Google Earth's network link on (but running on localhost, of course).

I'm a relative outsider to the wigle community. However, the project is superb and interests me greatly. But the most amazingly baffling thing to me is that the project continues to emphasize and depend on its own mapping system.

The system is a superb effort, but that's not the point. The point is that wigle developers could be liberated to be concerned with data and other things, and outsource the mapping to a system under aggressive development by a major corporation -- Google. It's insane not to leverage that, and this is something that leaves a wigle outsider like me shaking his head in amazement.

The only sane way -- let me emphasize that -- the only sane way to present this information in Google Earth -- or for that matter in Google Maps with a mashup -- is to use the bounding box method on a server app to return just that data that falls within the corner points of the map. You drag the map and change the corners, it's a new query to the server. You zoom -- same thing. This is the way the wigle maps work, as far as I can tell, so any method that leverages Google Earth that falls short of that is falling short of the mark.

That's not to impugn your work, but you might consider that the need to adopt methods that fall short of dynamic KML that's based on the geographic points that bound one's view -- the only logical parameters for a geographic query! -- is a reflection on some inertia that's keeping wigle attached to a salutary but redundant mapping application that should be abandoned.

I mean, let's be blunt. Is wigle about loyalty to a mapping application, or is it about the bloomin' data? Someone has to be honest and decide that.

I don't mean to be unkind; I emphasize that the wigle map is great. Your own work is a good effort. But why not leverage a behemoth who's throwing their weight into mapping, motivated by a business need to prevent Microsoft from passing them up in that area? That's a compelling reason for Google to work hard to make mapping platforms superb, and IMO that's a compelling reason for the wigle community to leverage Google Earth and Maps mashups, and focus on the data and creating a VARIETY of dynamic overlays that will deal with some of Google Earth's shortfalls -- like the inability to transform data layout in the interface itself (if you want things grouped by different criteria, it requires different dynamic links).

The rest of the on-line world is leveraging Google Earth and focusing on their data. That's the philosophical question -- is Wigle about proprietary maps, or is it about the data?

OK, there's my rant. Again, no ill will intended. And if this does engender any resentment, I won't perpetuate an argument -- I'll let someone else have the last word in this thread. That doesn't mean I'm not interested in wigle; I'm very interested indeed.

- Scott

[Dutch]

The only sane way -- let me emphasize that -- the only sane way to present this information in Google Earth -- or for that matter in Google Maps with a mashup -- is to use the bounding box method on a server app to return just that data that falls within the corner points of the map. You drag the map and change the corners, it's a new query to the server. You zoom -- same thing. This is the way the wigle maps work, as far as I can tell, so any method that leverages Google Earth that falls short of that is falling short of the mark.

You are making assumptions on how the webmaps work. The data on the webmaps are not realtime updated, but dumped to the Wigle webmaps renderer every once in a while, generally thought to be once every day, but not disclosed by the Wigle Founding Fathers.

Having a G.E. mashup query for new data everytime the bounding box moves will make the bandwidth costs prohibitive for the Wigle Guys. Even Jigle, their own mapping client uses caching of data previously downloaded. Remember, Wigle is a hobbyproject solely funded out of Bobzilla, Arkasha, and Uhtu's pocket, with the occasional donation from users, and sometimes sales of laundered datasets from loggings explicitly donated to that kind of sales.
I'm taking a SWAG guess here, but I would think that the bandwith costs with the current setup is still the biggest expense they have. And I'm quite certain that they are not generating revenue from Wigle, but are paying money to run their project of love. We are just the fortunate recipients of their hard work.

Imagine a 10 fold increase in bandwith usage (and thats pretty low set), if there was a mashup that needed to pull data down live, for each movement of a users viewport on G.E.. How long do you think they would be able to keep running their project, while still being able to afford a decent life ?

Dutch

[rasqual]

Not to argue -- just a question: what kind of (1) CPU and (2) network bandwidth differences are there for wigle between these alternatives:

(a) downloading graphical map imagery from wigle whenever a user wishes to view a different area, whether it's live data or cached

or

(b) downloading compressed differential KML data from wigle and graphical map imagery from google

I'd guess it would pan out like this:

1a low
2a high
1b high
2b low

The question would come down to whether wigle's proprietors wish to spend their hard-earned money on CPU or network bandwidth.

Just a thought.

Well, another thought (editing later, here): one of the things about a common platform is its utility for ad hoc purposes. If I'm in google earth looking at one thing, I might find myself suddenly realizing that I want to see about something else in the area of interest. To the extent that various institutional sources of information rally around such a standard, the promise of such inspirations bearing fruit becomes more promising. This is NOT an exceptional mere possibility; it's how life generally operates. But systems operating in separate interfaces, duplicating efforts and segregating data so synchronous collations of data from different sources can't be accomplished -- well, it breaks that chain. It makes a quest for one thing remain just that, with other actions then required to do more. And more often than not, "it's not worth the trouble" unless it's a significant thought. The beauty of having something like Google Earth where anything can be found once you have your dynamics of interest in play (in addition to the fundamentals of the interface, the GE community, etc.), is that even the most utterly trivial digressions may be pursued without the least concern about being inconvenienced by the need to alt-tab from the browser to another application and look up the coordinates there too.

Opportunism. What happens when you're doing something else. That's so much how we all think. Our use of information should cater to that!

[themacuser]

Imagine a 10 fold increase in bandwith usage (and thats pretty low set), if there was a mashup that needed to pull data down live, for each movement of a users viewport on G.E.. How long do you think they would be able to keep running their project, while still being able to afford a decent life ?

Dutch

Yeah. I'm probably not going to make my script work by location - at the moment, it's a search by SSID/BSSID, and it will stay that way for that exact reason.

.kismac has already done this: http://earth.kismac.de/ , but their service is much smaller than WiGLE (250k networks as opposed to 8.6 million here).

I'm not too sure WiGLE would hold up to doing this. Plus, their plugin doesn't even view all the networks - it would be way too many...

If WiGLE's TOS was a little less restrictive (someone else could mirror the db and provide this service), this may be a little easier... but that just opens a whole new box of cans of worms...