Yesterday Steve Coast announced that Bing had released a new tool for doing automatic road detection using satellite imagery. The concept is definitely interesting as it provides a way to rapidly generate road data over the entire globe without need of manual tracing.

However, I remarked that it was particularly interesting that Steve was working on this. Several years ago, when OpenStreetMap was still an ambitious but unproven concept many people argued that road detection was a useful, and perhaps necessary, mechanism for actually capturing all the road data. Steve was quite adamant that while it was possible – and he demonstrated it – it wouldn’t work for other reasons.

OpenStreetMap is more than just a set of lines that render to nice maps. It is a topologically connected, classified and attributed, labeled network of geographic entities. Each road consists of intersections, road classifications, names, speed limits, overpasses, and lanes. OpenStreetMap has provided a very rich set of linked, geographic data.

And beyond the data, it has built a community of invested members that careful capture, annotate, and cultivate the data in OpenStreetMap. This means that the data is captured, but also updated and maintained (ideally) with new information, changes, and other entities such as parks, buildings, bus stops and more.

So Steve convincingly pointed out that automatic road identification was interesting, it would circumvent these other benefits of what OpenStreetMap was working on: rich connected data, and a community of volunteers that would build and maintain the dataset. Road detection has a tendency to generate a large amount of data in an area that no one is actively working on the data. So you can gain what appears to be good coverage but limited local knowledge on intersections, names, and other metadata.

I don’t think that these are insurmountable problems. The act of capturing GPS data can be tedious, inaccurate, or not readily possible in remote areas. Road detection can provide this data and users can work afterwards to improve the data, either remotely or using even simpler mobile devices that a user can annotate features without having to capture the entire geographic road line.

So my comment the other day was about pointing out an interesting change in message and strategy. I applaud the work of Steve and the Bing team in developing new tools, but there are many other pieces that warrant consideration. Steve even asked often if the bulk import of the TIGER/Line data was good or bad for the US community. In the end, I believe it was the right thing as it provided a canvas of data using open data that provided a validity to skeptics that OpenStreetMap was viable and valuable.

Now that OpenStreetMap has become increasingly adopted by the world’s largest providers and users of data it is time to evaluate new tactics for gathering and maintaining data. However this can’t be at the expense of what made OpenStreetMap a success for the past 5+ years.

The United States had a much later start in OpenStreetMap than Europe and other parts of the world – but we also have a long history of open-government data that created less of a demand or need for grassroots mapping. However, the benefit of this culture is that the US government, from the local and state levels, all the way to the Federal level, are interested in utilizing OpenStreetMap and connecting with the community.

I’ll be speaking on Sunday about the necessity, and benefits, of moving beyond merely open data to instead focus on collaborative data gathering and mapping. Through our work on GeoCommons, OpenStreetMap, and deployments of data sharing to Afghanistan, Pakistan, and Haiti and how citizens with organizations need to engage together in dicussing the need for data, methods for collectively gathering, and ways to open share and capture feedback in order to improve the overall quality as well as impact of open data.

OpenStreetMap has understood this from the beginning in promoting through “mapping parties“. These parties had the explicit goal of mapping a region and training new mappers, but implicitly they created a community of like-minded local citizens that self-identified their desire to spend time and energy in working together to gather and open data. It is basic initiatives like this that are vital at the local and regional levels.

If you’re near Atlanta, or can come by to the conference, hope to see you there. And regardless, think about how you can connect within your community of interest to start a dialogue and collaboration around open data.

There have been several tremendous groups that have actively been contributing data and tools both with remote developers and responders on the ground. CrisisMappers, CrisisCommons, Ushahidi, OpenStreetMap, just to name a few.

Many data providers have been making their data freely available. This is most notable when looking at Mikel’s screenshots of OpenStreetMap before the quake and after volunteers began tracing over historic maps and newer satellite imagery from Digital Globe and GeoEye.

Other efforts:

• Ushahidi Haiti is crowd-sourcing reports. You can send a text message to 447624802524, send an email to haiti@ushahidi.com, or send a tweet with the hashtag/s #haiti or #haitiquake.
• The CrisisCommons Wiki has a list of available data and organizations
• Sahana has a form to list offices and organizations that are working on the ground
• GeoCommons search for Haiti has all the datasets and maps that people have contributed for download as Spreadsheet, Shapefile, KML, and more
• OpenStreetMap’s Project Haiti has a list of datasets and people tracing data

Mashable and James, amongst many others, have excellent predictions that will and won’t happen in 2010. Generally they are good insight into trends in the geo and mobile space, although I will take up counterpoint to some of his suppositions on File Formats, Interfaces, OpenStreetMap and Augmented Reality.

File Formats and Interfaces

Geo is definitely becoming mainstream – everyone in my family has a PND, uses Google Maps, and are asking about various location sharing applications. In the next year we’ll see geo become part of the assumed infrastructure, like the timestamp on a post or article, the location will be embedded.

I don’t think TAG (Twitter, Apple Google), as James puts it, will be the only location sharing services. They, along with even more used Facebook, will definitely be the general public interface to location query and sharing – but just because of this reason alone they will have to be very generic, leaving room for specialized location based services to still thrive in niches. FourSquare offers ‘gaming’ or Flickr visual media, and others for music, drinking, sight-seeing, and house finding. They will leverage TAG, or at least TG.

Apple is like the Nintendo of consumer technology – more interested in providing an integrated, compelling experience, and privacy, before full open-ness and engaging with the developer or geek. They’ll still have API’s, but not something like OpenSocial, GeoRSS, or FireEagle integration.

The iPhone, and to lesser extent Android, have been revolutionizing mobile devices. They are truly providing windows into the rest of the web of data combined with the real world. It’s natural for geopatial tools to move into these interfaces, but like any good user experience it won’t be the same capabilities you find on a desktop or browser application. The utilities will be specialized for the small screens, finger inputs, and out-and-about tasks.

For file formats, the Shapefile, unfortunately, isn’t near EOL. Too many tools only speak shapefile, and there is numerous legacy data that is still only available in Shapefile. Sites like GeoCommons offer alternate formats for all the data, but that still won’t remove this basic format. Only when there is a truly open, license free, API to File GeoDatabases (FGDB), and every off the shelf tool can talk that API or Spatialite, will Shapefiles begin disappearing out.

GeoRSS and/or KML, on the other hand, will be in every service that does anything Geo. Looking at any iPhone App review that includes KML (or doesn’t) brings up this point. Near enough everyone has Google Earth on their desktop, and Google is making big pushes in the utilization of Google Earth Plugin for in-browser virtual globes.

Visualization Technologies

To date, we’ve been stuck with either Flash or JavaScript DOM magic (and yes, Silverlight is out there too) in order to do data and geospatial visualization in the browser. As I mentioned, Google has been pushing Google Earth Browser, but also more generally they released O3D, a modern incarnation of X3D, providing for more general capabilities for creating 3D browser experiences. VRML lives!

More recently, there has been a resurgence in vector graphics that don’t rely on proprietary technologies or additional plugins. SVG and Canvas support is pretty widely supported except in the infamous Internet Explorer (which I hear is still being used even today). Examples such as ProtoVis, Cartagen and Tom Carden’s experiments definitely demonstrate that SVG is just on the cusp of being able to do a majority of compelling visualizations capabilities.

Another driver for alternative visualization platforms is the drive to mobile device integration. I don’t see Apple allowing Adobe onto the iPhone anytime soon, and even Android doesn’t have support. What types of visualization make sense is still a very open question – but whatever they are will be done with something like SVG.

Geo Data Skirmishes

James suggests that OpenStreetMap “won’t dominate”. While it won’t dominate, I disagree that it won’t continue to be extremely successful.

Google has recently moved to gathering their own data. They still have a long way to go, with many, many errors in roads, areas, addresses, and businesses and they’re using the crowd to help clean it up. Google is in fact proving the crowd-sourced model. It will be successful. Google is doing it with Google’s data, so there is no positive external benefit to that work – so to the industry it just looks like another data provider. However, with this proven model OpenStreetMap will succeed since any effort built into OSM has a positive benefit to anyone else.

However, there is a major difference in the trajectory OpenStreetMap is taking in the United States compared with Europe and other regions. In most other countries, the governments had very draconian licensing and as such OpenStreetMap was creating data from blank areas – starting from scratch, and building a community of volunteers along the way.

By contrast, in the US a vast majority of the data is free, and becoming more available everyday under the new administration. Therefore the US has a broad coverage of decent data without having first built the user community. So the difficulty here is both in building out community, as well as engaging companies that can do the same thing on their own while retaining proprietary rights to the data.

What’s fascinating, and what signals the ultimate long term success of OpenStreetMap, is that US state, local, and federal government agencies themselves are engaging with OpenStreetMap. They are investigating how to put their data directly into OSM, and possibly even re-incorporate updates and modifications back to their own infrastructures. Some are even considering using OSM toolset as their infrastructure. OpenStreetMap is going through some growing pains with respect to licensing, maintenance, and community – but all necessary steps in moving from a small cadre of hackers to a global, public project.

As we see an increase in open government, specifically driven by the US Administration’s directives, as well as other initiatives such as INSPIRE, this embrace and utilization of open platforms, and repositories, for sharing, federation, and syncronization of data will increase.

And as for augmented reality, it won’t be as big as you think… yet.

So of course, like any village, it needed to be mapped. I went down Saturday afternoon and captured the locations and names of all the buildings and paths that will be up for the week. These are then loaded into OpenStreetMap with start_date and end_date tags that notify the renderer when the features should be visible. It’s a similar model to how Burning Man is mapped year after year as it walks along the Black Rock Desert.

It’s ephemeral mapping – objects that exist in real place, but just for small slices of time. Important as any other building, yet typically relegated to flyers or verbal descriptions.

The fascinating part of projects like this is that OpenStreetMap allowed me to create a map that was useful and immediate. Within minutes of uploading the data, it was available as rendered tiles, vector data, and downloadable to GPS units and iPhones. People on the mall could immediately view the local map with this new information.

It’s a nice demonstration of how community projects like OpenStreetMap will continue to innovate faster, and more openly, then other ‘crowd-sourcing’ options.

It’s this transition from primarily ground-swell supported projects into industry supported efforts that makes them sustainabile. Linux went through the same growth as providers like RedHat and Canonical started putting full-time and dedicated resources to ensuring the continual growth and stability of the projects.

This is perhaps very interesting news to CloudMade, since it sits squarely in their market as well – and also Prioleau, the CEO former-CEO and now advisor of CloudMade was formerly a Vice President of Marketing at deCarta.

CloudMade and DeCarta tiles using OpenStreetMap data

The deCarta tiles show the copyright “CCBYSAODBL”, already including the forthcoming migration to the ODbL terms. There have been many companies that are interested in integrating OpenStreetMap into their products but concerned about the potentially unclear terms or permitted uses of the data that don’t inadvertently expose their proprietary data. Hopefully more moves like deCarta to utilizing OpenStreetMap in commercial products will provide clarity on the benefits and implications to other companies.

Last night we kicked off MappingDC, a local OpenStreetMap chapter for Washington, DC and the surrounding metro areas of Virginia and Maryland. It held at HacDC, a hardware hacker enclave in Columbia Heights Neighborhood and led with much enthusiasm by Serge.

Where traditional OSM mapping parties are about raising awareness, MappingDC will focus on identifying local open datasets, building relationships with organizations, running hyper-local mapping parties to map neighborhoods, and other technology and outreach projects. We brainstormed on initial datasets we could clear up licensing issues such as from DC GIS.

We created a few new sections in the Washington DC wiki page: datasets, mapping groups, and projects. The Datasets is a list of departments or organizations that may have data that would be useful to import and a point of contact and MappingDC member that will reach out to them to work on getting it released into OSM. The mapping groups are to identify who would like to help out with local neighborhood mapping and once there are 4 or so people, setup a day to meet and go out and map it. The last section, projects, is brainstorming around how developers can work on building out useful tools such as geochat, or DC specific map styles such as metro lines, bike routes, or other characteristics that match with local culture and features.

Our first event will be mapping Silver Spring, Maryland on August 8th. Watch the wiki page for more details, subscribe to the mailing list, and follow on Twitter.

We want to build local OpenStreetMap such that it fits within the larger local community. Getting OSM working with local bloggers, transit discussions and planning, and who knows – perhaps powering the National Map?

The geocoder was built as part of our FGDC CAP Grant to help GeoEnable Government Tabular Data and utilizes the free and open TIGER/Line street data as well as various address parsing and metaphone components for US level address parsing. Also, not everyone can call to a web-service, abide by the terms of service, or be limited by the speed and amount of geocoding queries.

The reason we’re open-sourcing it because primarily an open-source geocoder has been a sorely missing piece of the open-source geospatial stack. You have storage, analysis, rendering, geolocation, and even routing – but not geocoding, at least not in an active project way. GeoCoder::US has been around for a long-time and well built, in Perl, and despite it’s long-standing solid service at geocoder.us, it didn’t fit our needs.

So instead we worked closely with Schuyler Erle, one of the original developers of GeoCoder::US, to rebuild it in a modular way (in fact he finished it once and promptly rebuilt it again), and also in a popular, modern language, Ruby(that we happen to use as well).

We’re also hoping to engage the community in building out the Geocoder. Right now it has components for the United States – but we hope that others will add components for their countries. OpenStreetMap is coming along very well with adding both ranged, and even parcel level, address data. So a good first task would be to build out an OpenStreetMap data importer.

Feel free to check out the code on GitHub – fork it, let us know what you’re working on, any issues you run into, and how we can make the best, and open-source, geocoder out there. Look forward to more detailed posts on how we built it and how we’re using it in GeoCommons and GeoIQ.

Later this week I’ll head back over to Europe for State of the Map (SOTM), the annual OpenStreetMap conference. Three days of talks, demonstrations, brainstorming, demos, and camaraderie. In fact, GeoCommons is a Sponsor again this year (all three years and counting) with a very exciting and interesting surprise on how we’re supporting the conference.

Of all the upcoming conferences (Open Gov Innovations, GeoWeb, FooCamp) I have to admit I think SOTM is the most exciting. All the conferences are about change – incredible advancements that have come about in the past few years – but State of the Map has gone from a nascent concept, even an activist movement against the complex, and onerous licensing requirments of geospatial data in the UK, to a global phenomenon that is being leveraged by individuals, companies, governments, and global NGO’s.

For verification, take a glance at the OSM statistics. Two years ago there were just 8,000 registered users, last year there were 40,000, and today there are more than 124,000 users! The “Year of Edits” video never fails to leave an audience speechless and amazed. The US WhiteHouse is using OpenStreetMap and projects like WikiProject Palestine Gaza show that OSM is the tool people now turn to in a time of crisis and for data.

On Sunday I’m giving a talk about how we’re using OpenStreetMap in GeoCommons and our private GeoIQ servers: “Enterprise and Government Visualisation Analytics using OpenStreetMap”. It’s just one example of many about the power open and crowd-sourced data has in supporting and growing businesses and serving customer and citizen needs. Other companies such as CloudMade, DevelopmentSeed, and itoWorld are also building out the ecosystem that is necessary for open, community projects to have a longevity.

There is an entire suite of tools that has been given form and purpose because of the huge amount of open data. Mapnik and other map rendering engines have data attributes to style; JOSM, Potlatch, and other vector editing tools are beginning to provide more compelling, and non-expert interfaces for modifying topological, geographic data; GPS export, data licensing, navigation and routing are more problems that have been explored and solved through the OpenStreetMap community.

So I’m excited about State of the Map because it means a result of thousands of individuals hard work and aspirations culminating in a meeting to celebrate what has been accomplished and also set goals to much higher, and diverse peaks. It’s proof that a crazy idea of people running around with GPS receivers can make a real impact.

Whether you were already serving your country, or are responding to the President’s call, share how you are delivering on change in your community.Whether it is an hour per month helping those struggling in the current economy, tutoring kids in your neighborhood every day, or anything else, we want to highlight what Americans are doing to strengthen our country.

This is very interesting on several levels. Foremost is the use of government provided (TIGER/Line) and crowd-sourced data (OpenStreetMap) in an official US Government Site. This is definitely an indicator that what were cutting edge tools have reached a critical mass to provide broad usability and appeal. Open Source? check

Looking underneath the hood, the data is provided via a KML feed (), so you can pull the data out and upload or map it however you want. Open Data? check

The site itself, Delivering on Change, is asking citizens to contribute stories and media about their personal engagement with change. This is an incredibly exciting step to ask for people to contribute to national storytelling and character. Citizen-sourced data? check

The new US administration is continually doing amazing, and open, initiatives. There is incredible excitement around Recovery.gov as a testbed for the next generation of transparency and embrace of technology and open data feeds.

Small next steps

My thoughts on interesting applications wouldn’t be complete without pointing out a couple of suggestions. While many defend the default OpenLayers controls – I personally think that implementors should take that next step and apply minor customization to better integrate the look and feel of the map controls into their site. I’ve talked before about how easy it is to change some CSS to replace the controls. Perhaps even just a darker blue background to match the White House blue in the logo. Customized?

Another, less highlighted but very important for Government sites is the integration of accessibility controls. OpenLayers supports map navigation using keyboard inputs – which provides for alternative interfaces to navigate the map. It’s not clear if this is official “508 compliant”, but at least demonstrates the potential. Accessible?

How you can help

So do you want to help make Change, especially with mapping data and technology? Come join us at the Washington, DC mapping party – currently planned for June 20 + 21, 2009 somewhere in DC (details coming soon). Or join a mapping party near you.

Out of the box, the OpenStreetMap style, osm.xml, doesn’t have fallback font support. What this means is that when the default font, DejaVu Sans, is missing the specified character then Mapnik doesn’t know where else to try to get the character. Mapnik has support for this, but for some reason the default OSM style or package doesn’t include it.

Thanks to the late-night help of Dane Springmeyer (and looking past the very bad April Fools joke of telling me Mapnik now has Ruby bindings and KML rendering support), I managed to get it working.

Steps to Reproduce

The solution is quite straight-forward, and I have added my notes to the OSM wiki on Mapnik.

1. Download the GNU Unifont Glyphs.
2. Unpack and put the ttf file in your /usr/local/lib/mapnik/fonts (or appropriate path) directory with the other Mapnik fonts.
3. Modify your osm.xml. Replace face_name="DejaVu Sans Book" with fontset_name="DejaVu Sans Book".
4. Underneat the <Map/> declaration, add the font set styling for fallback:

   <FontSet name="DejaVu Sans Book">
   <Font face_name="DejaVu Sans Book" />
   <Font face_name="unifont Medium" />
   </FontSet>
   
   

5. Repeat for Bold and Oblique.
6. Delete your tile cache and re-render.

You can view my modified osm.xml here.

It is really impressive how well Mapnik and OpenStreetMap work together, and the simplicity of styling. The next step is to figure out how to add English names to all the local language renderings, so that someone can look at תֵּל־אָבִיב-יָפוֹ and also recognize it as Tel-Aviv.

To address this, the OpenStreetMap Foundation Board has pursued the development of a more applicable and friendly Open Database License, ODbL. The goal of this license would be to make it clear the legal protection of geographic data gathered and how it can be used with other data or derived from.

It is a sign of maturity that an open-data project like OpenStreetMap is dealing with the legal issues that surround the otherwise grassroots crowd-sourced community. Similar parallels occurred with the development of GPL and BSD with open-source software and the Creative Commons in user-generated media. Open-Data is following in the footsteps of open-source, from grassroots “hackers” to disrupting some industries and redirecting others.

You spilled your legal all over my data

However, one difference that has affected these two examples is a valuable guide with how the ODbL and other similar licenses should progress. Software licenses are currently a myriad of acronyms and terms: BSD, MIT, GPL, Affero, Apache, and more. SourceForge has a deprecated license guide and in fact offers at least 72 license options.

The result is a confusion to both software producers and consumers. What licenses enforce which restrictions and usages? How can I bring together software under different licenses and their miscibility. This is a question that even after a decade of mainstream open-source experts still ask for advice.

A working model

Creative Commons headed this off through some nice modularization of the most popular options. Through clear naming, definitions, and iconography users can understand the concepts encased in otherwise unapproachable legal contracts such as Non-commercial, Attribution, Share-Alike, and No-Derivatives with straight-forward choosing of which modules any user wants to apply to their work.

This results in easy, lightweight sharing – encouraging people to contribute to public repositories and also make use of these works. By having simple, well understood licenses, one example is Flickr’s simple search filter that makes it easy to find Creative Commons only images for use in third party materials and presentations. It’s even possible to visualize and determine how you can mix together content released under various modules.

The overall result is that the license has become popular and encourages both sharing and use of shared media – effectively ending the future of traditional stock photography.

Open Data Modules

My point of highlighting Creative Commons is to look at how simple mechanisms can promote effectiveness around licensing of information. The ODbL’s primary purpose is making it clear how to produce and use OpenStreetMap data, but in this action it is addressing the growing need to easily define how the true underlying strands of the web will be shared. You can read a draft version of the ODbL.

The opportunity is to lead the charge on clear, understandable data licenses that citizens can take to their governments to demand the data be released under these terms. There would not be the need for click-throughs of unique terms of service or agreements, but easily shareable data that magnifies the power of any available datasources.

One counter-point to the pre-defined modules is that users that want variations can “select, modify, or delete” sections as necessary. This is definitely not an option – as it will create unclear and probably invalid licenses. In addition, these variations and spin-offs will be unvetted and untrusted. By handling the majority of cases under one common umbrella, the validity and attractiveness of a standard license decreases the difficulty of any organization to claim it wouldn’t work for them.

I posited this question to the OpenStreetMap Legal mailing list hoping to spark a discussion with the various people currently involved with the license. So far the feedback has surprisingly been negative on the benefits of modular based licenses. OpenStreetMap has a long road ahead even after a new license in drafted in convincing the very large community to switch licenses – an effort I hope does not negatively impact the organization but instead illuminates the need for clear licenses from the start of any open data collection project.

With GeoCommons, we are spending a lot of resources gathering, annotating, and sharing out open data sources. Our metadata catalog is shared under a Creative Commons Attribute, Share-Alike license. And nominally all the data we bring in is somehow open, under different monikers. But right now it is very difficult to easily share out the terms of these licenses – so the onus is upon the user to properly use each dataset. With our goal of making geospatial data easy to use for non-experts, we have a very high interest in making geodata licenses as easy to understand as photographs or articles are under Creative Commons.

An open question to open data licenses

The question here is whether the module concept of Creative Commons is an effective mechanism that should be applied to the Open Data License. The goal is to make it so easy for anyone to share information that it would take more effort not to do so. That this type of easily shared information is highly preferential by consumers that other datasets under various and unclear licenses such that these other sources conform to best practices.

What do you think is the best path?

If you haven’t been to a mapping party – essentially anyone can show up throughout the day, borrow a GPS unit (or bring your own), get a quick tutorial on how to collect data for OpenStreetMap and then head out for a gorgeous day around the town gathering tracks, points of interest, road data, bike trails, walking areas, etc. It’s a great way to explore the city and also make maps that are useful to you! While the OSM map for Arlington and DC “looks” fairly complete it’s missing a lot of useful information such as directions, metros and more – so it still needs a lot of TLC.

Once you get back with your data we can show you how to upload it to OpenStreetMap. Of course, there is also typically post-mapping socializing somewhere nearby. Overall the day is very free and you can come for as short as an hour or two – but I’ll warn you that it’s very addictive.

The event is listed for both Saturday and Sunday – but my recommendation is to come on Sunday. Saturday is SocialDevCamp East up in Baltimore, and also on Sunday Mikel will be in town to provide his mapping expertise to the party.

Here are the event details (in hCal of course).

There are several easy ways to fix this. The first was to look at the Ditu tiles, and confirm they are the same as Google’s nominal tiling scheme. Which means you can add the China Street tiles as a simple GTileLayerOverlay with Google Maps standard satellite view underneath. This was incredibly easy with Mapstraction and I put up a demo here.

For bonus points I even added a Mapufacture syndicated feed of Erik’s venues for LocWeb2008 and nearby Wikipedia articles from Geonames.

The other way

The terms of how mixing Google’s various tiles together isn’t clear. So the other way to address his issue is to use the freely available data.

Namely, OpenStreetMap for roads, OpenAerialMap or other remote imagery, and run in OpenLayers. Here is the same map done with open data and open source. The resolution or completeness isn’t there yet, but you can see where it’s going and the ability to be use the information as you want is very appealing.

We tried a number of methods – it should be as simple as changing the tile url that the Maps application queries. But initial “peeking” under the hood didn’t reveal where GMMServerURL is set. In the meantime – Mikel ended up finding the tile cache sqlite database (you don’t want to continually download tiles) and stuffing it with OSM tiles instead. So as far as the Maps application is concerned, its serving cached tiles. Pretty slick.

As Mikel points out, there are some issues to resolve – tile sizes are different on the iPhone, so the zoom levels are off. That would be easy to verify by loading a KML file with markers.

It’s also a slightly sweet answer to Google’s Cease & Desist to MGMaps for using the tiles. Mikel’s “hack” shouldn’t violate anything, he’s just be very considerate to his data provider by pre-caching tiles that have amenable TOS.