Schlagwort-Archive: development

Study Project – ArcGIS Server – Results

The study project ArcGIS Server – Client/Server Setup and Development for Geospatial Learning (introduced here) finished with some nice developments and results. The groups developed different applications and conducted usabillity-testing at a school in Muenster. The results of these tests were incorporated into the applications.The individual applications were developed as lightweight web based applications and were based on different frameworks. Topics that were covered by the developed applications were:

If you are interested in the individual implementations of the projects, get in touch with us, we will put you in contact with the authors. The magazin Arc Aktuell by esri will also feature this study project in their upcoming issue.

The new issue has just been released, more on this here.


Hacknight the 2nd

As I mentioned here some results from the Hacknight we had on the 3rd of December. We were three groups (2–3 people each), one playing around with the OLPC server, another one which tryed to work out the collaboration stuff and the third one which targeted to integrate GPS positioning in the application.

Here a short summary of each group:

OLPC Server

Target was to investigate if the OLPC XS is capable to act as a Tile@Home server. Tile@Home is similar to the classic SETI@HOME where you were able to share CPU time with NASAs efforts in searching for extraterrestrial life when your computer was in idle state. Well, we’re not really  interested in extraterrestrial life (at least that night ;-)), but wondered if XS has enough power to act as an OSM tile server. The main idea evolves from the fact that internet is not a safe thing in rural areas. If there is an internet connection, the school server could share it and all XOs would be able to download tiles from servers like the mapnik tile server. But if there is no internet connection, the server could either

  1. has cached all tiles (of interest) or
  2. even calculate its own tiles from a local OSM database.

Both possibilities are quite  interesting.

However, to simplify the work we decided to concentrate on the caching variant. For this we set up a small server script delivering tiles which are already cached on serverside. See on the Hacknight Twiki for some code.

Collaboration

Getting connected with other XOs is important to create a colloborative game. The second group wanted to find out more about the sharing functionality of an ativity. For this, we created a small activity reading out information about other XOs connected to the mesh network.

Nicknames,  Hashcodes and other attributes could be read out. Unfortunately, no exchange of custom data could be established at the Hacknight. Nevertheless, the basic steps and experiences were made we can build on.

GPS/Position Integration

Location is essential and probably the most importatnt thing when communicating and mediating geospatial conciousness. Running the great GPS daemon gpsd (for now we’ve to start it in the terminal, but it wouldn’t be too hard to start it from python, I guess), we extract the gps info via python gps module and keep it up to date every three seconds:

<br />
#!/usr/bin/env python<br />
import os<br />
import gps<br />
import time<br />
import logging</p>
<p>import utils<br />
import constants</p>
<p>LOGGER = logging.getLogger('position-logger')<br />
utils.init_logging(LOGGER)</p>
<p># this prepares for intended start of gpsd from terminal (e.g. gpsd /dev/ttyACM0)<br />
_FILE = open(os.path.join(constants.CONFIG_PATH, 'gpsdevice'))<br />
_DEVICES = [dev.strip() for dev in _FILE.readlines() if not dev.startswith('#')]<br />
if len(_DEVICES) != 1:<br />
    LOGGER.warn('Check your gpsdevices config file.')</p>
<p>try:<br />
    GPS_SESSION = gps.gps()<br />
except:<br />
    GPS_SESSION = None #IGNORE:W0702<br />
    LOGGER.warning('Could not initialize GPS session.')</p>
<p>###################################################<br />
class GPSReceiver():<br />
    """Receives GPS signal from gpsd Daemon.</p>
<p>    TODO There is a dbus alternative. . .<br />
    """<br />
    def __init__(self, gps_infos):<br />
        """Creates GPS_SESSION."""<br />
        LOGGER.debug('Create GPSReceiver.')<br />
        self.result = gps_infos</p>
<p>    def get_position(self, query='admosy'):<br />
        """Gathers the current position information."""<br />
        try:<br />
            GPS_SESSION.query(query)<br />
        except:<br />
            LOGGER.error("No GPS connection possible. ")<br />
            raise StopIteration, "No GPS connection possible. "<br />
        if GPS_SESSION:<br />
            self.result['latitude'] = GPS_SESSION.fix.latitude<br />
            self.result['longitude'] = GPS_SESSION.fix.longitude<br />
            self.result['utc'] = GPS_SESSION.fix.time<br />
            self.result['altitude'] = GPS_SESSION.fix.altitude<br />
            self.result['eph'] = GPS_SESSION.fix.eph<br />
            self.result['epv'] = GPS_SESSION.fix.epv<br />
            self.result['speed'] = GPS_SESSION.fix.speed<br />
            self.result['climb'] = GPS_SESSION.fix.climb<br />
            self.result['satellites'] = GPS_SESSION.satellites</p>
<p>            if self.result['latitude'] == 0 and self.result['longitude'] == 0:<br />
                # wait if gps has not been initialized yet.<br />
                LOGGER.debug('wait for connection')<br />
            #LOGGER.debug(self.result)</p>
<p>###################################################</p>
<p>if __name__ == '__main__':</p>
<p>    infos = {'latitude'  : 0.0,  # WGS84 latitude<br />
             'longitude' : 0.0,  # WGS84 longitude<br />
             'utc'       : None, # UTC time<br />
             'altitude'  : 0.0,  # m over sealevel<br />
             'eph'       : 0.0,  #<br />
             'epv'       : 0.0,  #<br />
             'speed'     : 0.0,  # current speed<br />
             'climb'     : 0.0,  #<br />
             'satellites': 0     # #satellites<br />
             }</p>
<p>    recvr = GPSReceiver(infos)</p>
<p>    for i in range(0, 100):<br />
        recvr.get_position()</p>
<p>        print 'latitude    ' , infos['latitude']<br />
        print 'longitude   ' , infos['longitude']<br />
        print 'time utc    ' , infos['utc']<br />
        print 'altitude    ' , infos['altitude']<br />
        print 'eph         ' , infos['eph']<br />
        print 'epv         ' , infos['epv']<br />
        print 'speed       ' , infos['speed']<br />
        print 'climb       ' , infos['climb']<br />
        print infos['satellites']</p>
<p>        time.sleep(3)<br />


Hacknight

On Thursday we had out Hacknight. I’d like to give some results and impressions of that event, but the fact that I closed the door at ~3.30 am tells me that it was quite successful. Honestly, I didn’t expect more than 5 participants (in fact we were 9 participants). However, I’ll split the summary of the Hacknight in two posts, this one about the plan, preparations and what some problems we had. A second one will tell s/th about results we made and the next steps.

We started at 5 pm with some introductory words and gave an idea of OLPC, the activities in Rwanda and our own project. After a short Python intro, a coarse idea of how Sugar and activities are wired together was procured. We didn’t get into details here, because we had some special challenges to investigate which mostly hadn’t to much dependency to Sugar. These challenges were:

  • Collaboration: Exchange some status data
  • OLPC Server: Setup an XS to serve as OSM tile server
  • GPS: Positioning and tracing
  • Openlayers & Co.: Javascript and Python communication

This is definitely not an exhaustive list, one could investigate when new to OLPC, Sugar and activities, but enough for one event, I guess.

For the first part we setup a development environment on the notebook of each participant. This was a bit more combersome I expected. We installed a Fedora system with sugar on a portable VirtualBox which we then copied on each machine. With a zipped 2.5 GB file not to fast, though. Unfortunately on some machines it didn’t run at all :(. After all, installing VirtualBox and using the harddisk from the portable one worked.

I created an eclipse package with yoxos which is a tool to create an eclipse package containing all plugins, preferences, settings etc. you might want to use for a project with several participants. Stupidly, it did not fulfill some security issues the Fedora system required (I’m not a Fedora geek), so we had to install it from sources with appropriate plugins (which is not too hard, thanks to these great package manager systems).

Sugar and Emulator was already installed on the virtual harddisk so we only had to checkout the project code and link it in the ~/Activities directory. Yes, I could have done this on the virtual harddisk before, though, .. touche. At least,f or the next time the environment is prepared ;-).

The next post will give a summary of some results we made.

Invitation to Hacknight

We are planning an OLPC XO Hack-Night at the 3rd of December.

We wanna investigate several issues like XO network behaviour and application sharing. Also we are interested in the potential of the XS ($100-Server) and how it could affect our geomodul application leveraging caching mechanisms, etc.

Starting at 5pm we serve pizza and beer in the evening, so this would be more joyful and socializing event! We meet at the Besprechungsraum 3. (german) Floor CIP Pool 5th floor (german!),  IfGI Weseler Str. 253, 48151 Münster.

If you have questions or want to give feedback please send an email to henning.bredel [at] uni-muenster.de