Links: Ipoki, Geoflock, OS in GE, C-GPS2KML

  • Ipoki: The idea of letting friends know where you are live on the map and following friends around yourself is a pretty seductive one. I’ve been using GMap-Track on this blog to update my whereabouts, but that application is not the only player in this geosocial application space. Now there is Spanish-origin Ipoki, newly relaunched (it used to be called hipoqih) and ready for the big time. Ipoki works as a small application on GPS-enabled phones, or you can also set your location manually from the website.

    The functionality of Ipoki and GMap-Track is very similar: Both have privacy controls, people search and the ability to let you embed a live location map on your website. Ipoki has a few more Facebookish features, such as a “what you are doing” status line you can fill in and commenting features. Ipoki also lets you view your friends as a live KML network link, and lets you link to unique permalinked pages to track individual users (I am at

    But GMap-Track’s phone application, Mobile Gmaps, hasn’t been standing still — the latest version allows you to load KML files direct from your memory card, which is a great way to take KML data into the field with you. (Extra tip: Use Gmap-Track’s public map to compare Yahoo, Microsoft and Google’s map offerings, as all are available to choose from.)

  • Geoflock: Got Flock? It’s a newish, free social-networking savvy browser that appears to be having something of a resurgence. If you do, get Geoflock, a plugin that gives you a wealth of mapping tools within the browser. For example, it can

    Create and save a sidebar map using the addresses or address links you find on web pages, or by manually adding locations. Show traffic Info, drag and drop kml files and geotag Flickr photos within the Flock photo uploader. There is a great deal of additional functionality which is hard to sum up, such as automatic geoURL/geotag discovery, support for Google Earth,, getting directions;…

    Automatic discovery and viewing of maps relevant to a web site is a great bit of functionality, methinks.

  • Ordnance Survey in Google Earth: Ah, finally, UK’s Ordnance Survey’s mapping tiles are put to use in a productive manner — as a dynamic overlay in Google Earth, thanks to Gavin Brock. No doubt this breaks all manner of EULA, but check it out in the meantime as an example of what the data could do it if it were open and freely accessible:


    (Via Naquada)

  • GPS2KML: C-GPS2KML is not the first application to convert GPS logs to KML, but it does have an impressive feature set and a myriad of display options. It’s free, comes in Windows and Linux versions, has a detailed manual, and the screenshot eye candy is very enticing. Check it out. (The only competitor I can think of when it comes to similar customizable display options is the web-based app GPS Visualizer)
  • Virual Earth dataset update: Microsoft Virtual Earth comes out with another mammoth dataset update, including 15,000 square kilometers of 3D urban landscapes (almost all of it in the US) and heaps of bird’s eye views, aerial and satellite imagery (a bit all over).

    Reaffirming a previous observation: Microsoft’s data gathering priority is above all urban areas, and primarily the developed world, whereas Google’s collection is far more indiscriminate — but in a good way: If, as Thomas Friedman argues, “the world is flat”, this is in part because even out-of-the-way places can now finally get equal footing in the cartography stakes.

  • ESRI ArcGIS Explorer update: James Fee points us in the direction of a new release of ESRI ArcGIS Explorer — Build 440. My favorite new feature: Popups can use a full complement of HTML tags, including Javascript and CSS! Now wouldn’t it make everyone’s life easier if KML supported that?!
  • Geology visualization: Frank at Google Earth Blog and Richard Treves at Google Earth Design write up a great new geology visualization technique using Google Earth by Declan De Poar of Worcester Polytechnic Institute, presented at the AGU’s annual conference last week.

7 thoughts on “Links: Ipoki, Geoflock, OS in GE, C-GPS2KML”

  1. If you want to do this legally then you can do this through some OS Partner sites that actually have their own servers serving at all scales (even down to individual buldings at 1:500 scale) using different (faster) technology including WMS. You just have to pay for it ;)

  2. KML might benefit from CSS and Javascript, though I think they would be wise to do it in a way that retains content semantics — in line with practices in (X)HTML. If they included a [limited] Javascript library to hook into via a ‘script’ tag in the header, along with a ‘stylesheet’ tag in the header for an external CSS file — one can link several or all KML files to that stylesheet or script library. In that case, it would probably be wise for Google to create their own scripting functions — and allow generic function-calls within KML.

    This would be the ultimate, scalable way to go about it, without compromising security — and retaining proper document semantics. I’m also not sure how one would philosphize the DOM (Document Object Model) in the case of presentation within KML, in comparison to web documents.

    I also shudder to think the kind of phishing, spam, and hacking attempts that’ll occur if the full Javascript engine is hooked to KML. This is why I think it might be prudent to build a library in this case, that’s always accessible to KML. CSS is more a principle of the separation of content and style.

  3. I’m tired at the moment, so bare with me — I’m still experimenting with WV1 samples, so you can imagine I’ve been getting marginal amounts of sleep.

    I also wanted to point-out that HTML 5 is in development — so you might want to take a look at what’s planned there and the direction that things could potentially go. It’s still a few years away from release, but looking through it there’s some major things of note included that’ll re-shape the way HTML is implemented in KML [and other geo-browser languages], and that could very well offset the direction of scripting implementation.

    I think this is where much of my concern for how to go about implementing scripting in KML comes from — why I lean toward an API-style library for the core. I’d just hate to see another language end-up in the same use-scenario as HTML has all these years, where the common approach becomes total lack of sensativity toward semantics and functionality, and hacking it inappropriately, causing any range of problems associated with what we call ‘code soup’. It’s taken years to get anyone to recognize the value of semantics and the separation of content, style, and scripting — I’d can’t help but hesitate when I see the geo-spatial-heads rush to implement something without the considerations that some of us have experienced 100-times over in the web world all these years. (And coming into the geo-spatial arena, for me, is like being set back literally 10 years in the mindset of how to go about web implementation!)

    I’m also a huge proponent of the separation of content, scripting, and style — unless it’s absolutely necessary to include a script within the document or within a tag. (I actually can’t stand scripts in tags — use a CSS reference!!)

    Since KML is an XML hybrid with the same key-tag model, I suppose it’d be interesting if you could simply include script and CSS calls to each tag. That way, you can add the functionality and style without mashing it into the meat of the content.

    It’d probably be better explained with actual key examples, and how you’d call a script key depending on the document order (ie: script in header, drills down the document hierarchy and applies globally, vs. script for specific key in document, which would only apply to that key reference.)

    So anyway — yeah — I think people need to think before leaping in this case, otherwise we end-up back in the stone ages of the ‘code soup’ cycle all over again. Ugh.

  4. And. If the Javascript developers would just include one little native function that would make a standards approach actually spread like wildfire — it would to finally include a getElementsByClass call.

    That’s all I ask. It’s relatively simple. We’ve kicked and screamed for it for years — but nope, no getElementsByClass — you keep having to build your own, making code chunky, funky, and inaccessible — and most of all, doesn’t encourage separation, it undermines it.

  5. re. Ordnance Survey in Google Earth

    Wrong chart datum being used. GE uses WGS84, OS uses OSGB36. Needs converting.

  6. re: wrong datum

    Now fixed and using OSGB36. The north alignment is improved too.

    URL is the same as before. Enjoy…

Comments are closed.