<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="../assets/xml/rss.xsl" media="all"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Samat Says (Posts about OpenStreetMap)</title><link>https://blog.samat.org/</link><description></description><atom:link href="https://blog.samat.org/tag/openstreetmap.xml" rel="self" type="application/rss+xml"></atom:link><language>en</language><lastBuildDate>Fri, 29 Jun 2018 09:25:27 GMT</lastBuildDate><generator>Nikola (getnikola.com)</generator><docs>http://blogs.law.harvard.edu/tech/rss</docs><item><title>Spaceport America on OpenStreetMap</title><link>https://blog.samat.org/2012/01/11/Spaceport-America-on-OpenStreetMap/</link><dc:creator>Samat K Jain</dc:creator><description>&lt;div&gt;&lt;figure class="right"&gt;[flickr-photo:id=6639706995,size=m]&lt;/figure&gt;

&lt;p&gt;&lt;a href="http://www.spaceportamerica.com/"&gt;Spaceport America&lt;/a&gt; is "the world's first purpose-built commercial spaceport". Wonder what it looks like? You can now &lt;a href="http://www.openstreetmap.org/?lat=32.9891&amp;amp;lon=-106.97534&amp;amp;zoom=15&amp;amp;layers=M"&gt;find it on OpenStreetMap&lt;/a&gt;, one of the many things I've been mapping in New Mexico's barren &amp;amp; isolated &lt;a href="http://en.wikipedia.org/wiki/Jornada_del_Muerto"&gt;Jornada del Muerto&lt;/a&gt;. I've indicated various Spaceport America structures, like the state-of-the-art Terminal Hangar Building and Spaceport Operations Center. I've yet to accurately locate Spaceport America's vertical launch pad, which has been in use since 2007.&lt;/p&gt;
&lt;p&gt;No, it's not on Bing Maps, Google Maps, or any of the other Web mapping competitors—just in case you needed a reason why crowd-sourced geodata (or &lt;abbr title="Volunteered Geographic Information"&gt;VGI&lt;/abbr&gt;) can't be beat. &lt;/p&gt;
&lt;p&gt;Want an &lt;a href="http://www.flickr.com/photos/tamasrepus/6639706995/"&gt;aerial photo of Spaceport America&lt;/a&gt;? Over on Flickr I've a screencap from the USDA's public-domain &lt;abbr title="National Aerial Imagery Program"&gt;&lt;a href="http://en.wikipedia.org/wiki/National_Agriculture_Imagery_Program"&gt;NAIP&lt;/a&gt;&lt;/abbr&gt; 2011 release, pretty much the only source for high-resolution imagery of the middle of nowhere.&lt;/p&gt;
&lt;p&gt;&lt;a href="http://www.openstreetmap.org/?lat=32.9891&amp;amp;lon=-106.97534&amp;amp;zoom=15&amp;amp;layers=M" class="call-to-action"&gt;See Spaceport America on OpenStreetMap&lt;/a&gt;&lt;/p&gt;&lt;/div&gt;</description><category>Needs-Fixing</category><category>New Mexico</category><category>OpenStreetMap</category><guid>https://blog.samat.org/2012/01/11/Spaceport-America-on-OpenStreetMap/</guid><pubDate>Wed, 11 Jan 2012 00:00:00 GMT</pubDate></item><item><title>Monitoring Intel SSD lifetime with S.M.A.R.T.</title><link>https://blog.samat.org/2011/05/09/Monitoring-Intel-SSD-Lifetime-with-S.M.A.R.T/</link><dc:creator>Samat K Jain</dc:creator><description>&lt;div&gt;&lt;p&gt;The Internet is abuzz with talk about solid state reliability right now (see a &lt;a href="http://www.codinghorror.com/blog/2011/05/the-hot-crazy-solid-state-drive-scale.html"&gt;recent article by Jeff Atwood&lt;/a&gt;). Random, catastrophic failures aside, how can you know how much life you've eaten into your &lt;abbr title="solid-state disk"&gt;SSD&lt;/abbr&gt;?&lt;/p&gt;
&lt;p&gt;If you've an Intel SSD, it's pretty easy; they export a &lt;a href="http://en.wikipedia.org/wiki/S.M.A.R.T."&gt;S.M.A.R.T.&lt;/a&gt; attribute "Media Wearout Indicator". Starting at 100 (new), the attribute decreases to, well, zero. Forget how to do that on Linux? It's easy:&lt;/p&gt;
&lt;pre&gt;&lt;samp&gt;&lt;span class="prompt"&gt;$ &lt;kbd&gt;sudo smartctl -a /dev/sda | grep Media_Wearout_Indicator&lt;/kbd&gt;
233 Media_Wearout_Indicator 0x0032   098   098   000    Old_age   Always       -       0
&lt;/span&gt;&lt;/samp&gt;&lt;/pre&gt;

&lt;p&gt;The SSD in my laptop is at 98, and my oldest SSD in another system (from mid-2009) is at 97. Yours?&lt;/p&gt;
&lt;p&gt;On to the real news: the &lt;a href="http://www.openstreetmap.org/"&gt;OpenStreetMap&lt;/a&gt; project has &lt;a href="http://gis.638310.n2.nabble.com/Quicker-Tile-Rendering-td6342010.html"&gt;switched their tile rendering server to an SSD&lt;/a&gt; (hopefully making tile renders much, much faster). A newer, consumer-grade &lt;abbr title="multi-level cell"&gt;MLC&lt;/abbr&gt;-based Intel 320 Series 600 GB SSD, in fact. Conveniently, OpenStreetMap monitors their servers with Munin, which by default &lt;a href="http://munin.openstreetmap.org/openstreetmap/yevaud.openstreetmap/smart_sda.html"&gt;graphs all S.M.A.R.T. attributes&lt;/a&gt;, including Media Wearout Indicator.&lt;/p&gt;
&lt;p&gt;Other than the initial import of the tile rendering database, OSM tile rendering does not consume many write cycles. But it definitely hammers the disk to death on reads. Keep a lookout on these graphs to see how their SSD ages over time. Don't forget to &lt;a href="http://wiki.openstreetmap.org/wiki/Beginners%27_guide"&gt;contribute to OpenStreetMap yourself&lt;/a&gt; so we can see that number go down a bit quicker (I'm pretty sure OSM doesn't mind!).&lt;/p&gt;
&lt;p&gt;Note: &lt;a href="http://ksmapper.blogspot.com/"&gt;Toby&lt;/a&gt; mentioned to me that all the values appear to be pegged at 100. Most of these attributes are dummy values—only "Media Wearout Indicator" and "Available Reserved Space" appear to change with normal use.&lt;/p&gt;&lt;/div&gt;</description><category>Computer Hardware</category><category>Has-Comments</category><category>Linux</category><category>OpenStreetMap</category><guid>https://blog.samat.org/2011/05/09/Monitoring-Intel-SSD-Lifetime-with-S.M.A.R.T/</guid><pubDate>Mon, 09 May 2011 00:00:00 GMT</pubDate></item><item><title>gpxsplitter: Split GPX files with their waypoints</title><link>https://blog.samat.org/2011/02/15/gpxsplitter-Split-GPX-files-with-their-waypoints/</link><dc:creator>Samat K Jain</dc:creator><description>&lt;div&gt;&lt;p&gt;&lt;a href="http://wiki.samat.org/GpxSplitter"&gt;gpxsplitter&lt;/a&gt; splits multi-track GPX files, containing waypoints, into individual one-track &lt;a href="http://www.topografix.com/gpx.asp"&gt;GPX files&lt;/a&gt; with their respective waypoints.&lt;/p&gt;
&lt;p&gt;GPX files containing multiple tracks and waypoints jumbled together are produced on export by many GPS units, particularly MTK chipset-based devices such as the Qstarz Q1000 and Transystem i-Blue 474. Separating tracks and their associated waypoints was a headache until gpxsplitter came along. It's meant to be run first-thing after downloading data from your unit via gpsbabel or mtkbabel. It's a quick little script written in Python 2.x, with dependencies on mxDateTime and lxml.&lt;/p&gt;
&lt;p&gt;You can get it from the &lt;a href="http://gitorious.org/samatjain/gpxsplitter"&gt;gpxsplitter repository on gitorious&lt;/a&gt;, and the &lt;a href="http://wiki.samat.org/GpxSplitter"&gt;GpxSplitter wiki page&lt;/a&gt; is the one-stop place that will collect information about it.&lt;/p&gt;
&lt;p&gt;I thought about turning this into a web service, where users can upload their GPX files and have them split, but I'd like to know the demand for such a service before writing it. Ideally, gpxsplitter should be part of gpsbabel or something… but yeah, I'll save the XML parsing in C for a very, very rainy day.&lt;/p&gt;
&lt;p&gt;There are probably any number of bugs. If you find one, please &lt;a href="http://samat.org/contact.html"&gt;let me know&lt;/a&gt;—and send a testcase too!&lt;/p&gt;&lt;/div&gt;</description><category>GIS</category><category>OpenStreetMap</category><category>Python</category><guid>https://blog.samat.org/2011/02/15/gpxsplitter-Split-GPX-files-with-their-waypoints/</guid><pubDate>Tue, 15 Feb 2011 00:00:00 GMT</pubDate></item><item><title>Bing Imagery Misaligned at Lower Zooms</title><link>https://blog.samat.org/2010/11/30/Bing-Imagery-Misaligned-at-Lower-Zooms/</link><dc:creator>Samat K Jain</dc:creator><description>&lt;div&gt;&lt;p&gt;Microsoft's Bing aerial imagery (that's &lt;a href="http://opengeodata.org/microsoft-imagery-details"&gt;recently been donated to OSM for use in tracing&lt;/a&gt;) is offset by a few meters in some places.&lt;/p&gt;
&lt;p&gt;For example, earlier this week I &lt;a href="http://www.openstreetmap.org/?lat=31.90326&amp;amp;lon=-106.4485&amp;amp;zoom=17&amp;amp;layers=M"&gt;traced buildings&lt;/a&gt; with imagery from &lt;a href="http://en.wikipedia.org/wiki/National_Agriculture_Imagery_Program"&gt;USDA's NAIP program&lt;/a&gt;. Besides a history of being well-rectified, a GPS track in the parking lot confirms that I was spot on. However, on Bing with a low zoom, they're misaligned:&lt;/p&gt;
&lt;figure&gt;[inline-old:Bing-Misaligned.jpg]&lt;/figure&gt;

&lt;p&gt;Zoom in a bit, and they magically align again:&lt;/p&gt;
&lt;figure&gt;[inline-old:Bing-Aligned.jpg]&lt;/figure&gt;

&lt;p&gt;Apparently, different, well-rectified imagery is used at higher zooms. If I've found one problem, it then follows that it exists elsewhere. Be careful when tracing!&lt;/p&gt;&lt;/div&gt;</description><category>Has-Comments</category><category>Needs-Fixing</category><category>OpenStreetMap</category><guid>https://blog.samat.org/2010/11/30/Bing-Imagery-Misaligned-at-Lower-Zooms/</guid><pubDate>Tue, 30 Nov 2010 00:00:00 GMT</pubDate></item><item><title>OpenStreetMap "Geolocate me" user script</title><link>https://blog.samat.org/2010/07/20/OpenStreetMap-Geolocate-me-user-script/</link><dc:creator>Samat K Jain</dc:creator><description>&lt;div&gt;&lt;figure class="right"&gt;[inline-old:OpenStreetMap-Geolocate.png]&lt;/figure&gt;

&lt;p&gt;&lt;a href="http://userscripts.org/scripts/show/79016"&gt;OpenStreetMap Geolocate&lt;/a&gt; is a user script that adds a "Geolocate me" link next to the OpenStreetMap.org search box. If your browser supports it and you've granted permission, clicking on this link will center your map window to your location, as reported by your browser via the HTML 5 geolocation API.&lt;/p&gt;
&lt;p&gt;Say you've taken your laptop to a new cafe or conference—as soon as you open up OpenStreetMap, you can hit the "Geolocate me" link and quickly see what's around you, without fiddling with search or endlessly dragging the slippy map. Or, better yet, quickly add what's missing.&lt;/p&gt;
&lt;p&gt;This definitely needs to be built into the OpenStreetMap website.&lt;/p&gt;
&lt;p&gt;On most browsers, the &lt;a href="http://www.w3.org/TR/geolocation-API/"&gt;geolocation API&lt;/a&gt; uses Google Location Services or Skyhook, which determine your location based on nearby wireless 802.11 access points. However, some browsers, like Firefox 3.6 on Linux, can talk to gpsd and your GPS unit, so geolocation can get quite accurate.&lt;/p&gt;
&lt;p&gt;I've tested it on Firefox 3.6, Chrome 5, and Opera 10.60 (which, interestingly enough, is the first non-beta of Opera that supports geolocation). I've been told it also works on Safari 5.&lt;/p&gt;
&lt;p&gt;I should make a note in the interest of accuracy: geolocation isn't actually part of "HTML 5"—it's a product of the &lt;a href="http://www.w3.org/2008/geolocation/"&gt;W3C Geolocation Working Group&lt;/a&gt;. However, the need to be accurate didn't keep the XML out of AJAX, and by and far geolocation is one of the technologies people think about when they hear HTML5.&lt;/p&gt;
&lt;p&gt;This entry is cross-posted on &lt;a href="http://www.openstreetmap.org/user/SamatJain/diary/11287"&gt;my OpenStreetMap user diary&lt;/a&gt;.&lt;/p&gt;&lt;/div&gt;</description><category>Needs-Fixing</category><category>OpenStreetMap</category><category>Userscript</category><guid>https://blog.samat.org/2010/07/20/OpenStreetMap-Geolocate-me-user-script/</guid><pubDate>Tue, 20 Jul 2010 00:00:00 GMT</pubDate></item></channel></rss>