Technical Ramblings

Note to self:

The NMEA\_to\_DecDeg function is documented in Mapping Hacks, hack #62, “Build a Car Computer”.

(I’m going to be working quite a bit on my gsmlocation stuff in the next couple weeks, building up to a lightning talk presentation at Where 2.0 on June 13th. If you have a Bluetooth GPS and a Series 60 Symbian cell phone, please talk to me: I could use your help in building up a larger dataset.)

The Microsoft Cell Phone: Cute, quirky UI hides slow features in places that make sense to anyone who uses the phone for more than a year, but are confusing to first time users. Claims to cater to ‘Professional’ users, and therefore has enterprise versions of everything, but this means that the severs the phone connects to for all non-voice traffic are constantly down or unusably slow.

The Linux Cell Phone: Control options for everything, from the tone and volume of each keypress, to the type of digital encoding desired for voice. However, no one has yet coded a decoder for the digital transmission coming back from the cell towers, so all you get is a series of binary beeps. Mail to the cellphone-users mailing list asking if anyone is working on this feature is replied to with “Patches Welcome”.

The OS X Cell Phone: Originally build from the Linux Cell Phone, but with a working incoming decoder. Attempts to be the ‘hip’ phone include rotating images of the person you’re calling, and an intensive graphical display for every number entered when dialing. Due to its lack of ‘enterprise’ features, this phone is kept entirely out of the professional marketplace.

Okay, so it sounded better in my head than it turned out.

WMS is great… when it works. But having all my maps go busted because a server outside of my control decides that it doesn’t want to work today (today, the MassGIS WMS server, yesterday, a TIGER/LINE source I was using) is really annoying.

Oh well. At least one of my two basemaps is up.

Caching headers. Geoserver has an outstanding JIRA item about this, and a geoserver mailing list post describes the problem:

Putting squid in front of geoserver can help tremendously, but squid is very reluctant to cache anything without proper caching meta-information in the appropriate http headers.

This applies to mapserver as well.

Additionally, when running mapserver behind squid, libcurl sends “Pragma: no-cache” headers, so even if a remote mapserver instance supported caching (which it doesn’t), it wouldn’t be cached when behind a proxy. I think this is fixable by adding ‘Pragma:’ to the header setting code in maphttp.c, but I tried that and couldn’t get it to work.

The combinations of these would make tiling map apps much more realistic, since it would reduce load when requesting tiles from the map server.

In the vein of my previous post, I bring you another nifty trick: This time integrating Google Maps and Mapserver (kind of).

Visit static renderer. Browse Google Map. Then, when you’re looking where you want to be, hit the link up top, and off you go — transported to a world where data is public domain or licensed for re-use 🙂

I’m still trying to find a happy medium level of size of markers — when you’re zoomed way out, they’re too big, but when you zoom way in, they’re too small, so I don’t know what to do, but it *works* and that’s the important part.

Interface suggestions welcome — perhaps a side by side view is better? (I think I may be having a bit too much fun…)

After hours of fighting with Postgis, Schuyler finally got bia into a state where she would do the right thing when told to install it, so I was able to load the data from the Open Guide to Boston into postgis, and from there, to talk to it with mapserver. The result is a couple of pretty cool looking maps: Boston Metro, and Boston Metro Big, 1000×800 and 2000×1600 respectively.

The maps underneath are provided by Public Domain datasets, wrapped up in a tidy little easy to use package by the folks at OpenPlans through their “Sigma” project, and I’m extremely grateful to them for their efforts! They’ve saved me a ton of work, and allowed me to produce something that looks pretty damn cool.

If that’s not an advertisement for Open Geodata, I don’t know what is.

Number of people attending: 8 at various points in time

Topics Discussed:

* Copyright issues related to using Google Maps to geocode locations.
Alternative solutions to this type of behavior, such as openstreetmap
and openlayers. Quality of free map data.
* Museum project. Goals and aspirations for said project.
* Open Guide to Boston. Goals for project.
* Location-based services. Gumspotting. Cell tower based locations. Wifi
based locations.
* Demonstration of really nifty art-exhibit type interactive display from
Craig F., of Emerson College.

Establishment of next meeting time:

Meeting at Muddy Charles, from 5pm-7pm (or whenever), for drinks and
more socializing. This will probably become a regular meeting time,
barring extreme protest from members who are unable to participate.

Administrative: I will be posting a link to this message to the
geomancers-announce list. This message will inform readers that the next
such meeting will be next Friday, from 5pm-7pm, and that all discussion
should head to the discuss list.

Links discussed:
* OpenStreetMap: http://www.openstreetmap.org
OpenStreetMap is a ‘grassroots’ remapping project, using people with
GPSes who go out and trace roads, tagging them, and mosat recently,
working to generate pretty maps from the content.

* http://wiki.openstreetmap.org/index.php/Image:Sutton_Coldfield_ver0.2.1.png
* http://wiki.openstreetmap.org/index.php/Image:Dunfermline-2006-04-08.png
* http://www.openstreetmap.org/index.html?lat=51.50000023501376&lon=-0.116667&zoom=11

* Open Guide to Boston: http://boston.openguides.org/
The Open Guide to Boston is a wiki-based approach to local location
based information storage, using (mostly) free data as a boostrap and
offering integration with Google Maps for displaying and editing of
nodes. Also offers ‘nearby’ searches, and structured metadata
exported as RDF/XML.

* Skyhook/Loki: http://www.loki.com/
Windows-only system (at the moment) — determines location based on
nearby wireless access points

* Geocoder.us: http://geocoder.us/
Public domain data from the US Government put to use providing
geocoding services.

* Castle Square Wireless Project: http://www.cstoboston.org/wireless.htm
Castle Square is using the MIT roofnet software to provide wifi to
residents over a SpeakEasy DSL line rebroadcast in a mesh network.

* CMP Presentation: http://museum.mit.edu/files/presentations/2006-03-15-mwow/
The Collaborative Mapping Project is an effort to build a device
which allows the MIT museum to take to the streets of MIT and
Cambridge, and explore the history and richness of media of the world
around you.

* Platial: http://www.platial.com/
Using Google Maps to create your own personal atlas.

* Where 2.0: http://conferences.oreillynet.com/where2006/
Where 2.0 O’Reilly conference, Jun 13-14th, San Jose, CA.

* Cell Locative Services: http://iconocla.st/~sderle/cell/gallery/
Visual attempts at mapping cell phone towers to locations based on
latitude and longitude collected via a bluetooth GPS.

I’ve set up a mailing list for the Open Guide to Boston: sign up if you’re interested.

Likely topics on the list:
* Local get togethers to discuss the guide — technical, social, intro to beginners, etc.
* Requests for help in some aspect of the guide — looking for images, or help maintaining some specific feature.
* Discussion of changes made to the guide technically
* Discussion of changes made to the guide socially: policies, etc.

Thus far, there has been no traffic, but I’m about to change that, because I’m working on redesigning the site, and I’m a very bad designer. (I have a few tricks and tips I learned from working as one for far too long, but nothing that makes me qualified.)

So, if you’re interested, please feel free to join the list.