In order to facilitate that, I wrote a very simple tile viewer using Node.js and Leaflet. It uses a config file to get everything it needs to operate so we just make our changes there. This application currently only works with Web Mercator tiles but I’m working on adding support for WGS84. It also doesn’t work with ‘compact’ tiles from ArcGIS Server. It obviously requires Node, and it also requires an NPM install of the ‘open’ module to facilitate opening the browser.

Anything else you need to know is in the readme. I hope you find it useful. It can be downloaded here.

Over the past few weeks, I have been reading with conflicted agreement the posts of Brian Timoney and Bill Morris about the nature of geo-portals and what they should or should not be and do. I say that I am in conflicted agreement not because I take any issue with anything they have said. Their posts represent what should be considered best practices in terms of building web mapping applications. In Brian’s posts, the counter-examples he highlights represent some of the worst practices to be avoided.

My conflict arises from the fact that, while I agree with the ideas that Brian and Bill put forward, I find myself working against them in my current work. In my hangout with James Fee a couple of weeks ago, I mentioned that I am working again (albeit temporarily) in the world of Silverlight. I am supporting a very large, complex Silverlight application that, as one of many functions, includes a mapping module that runs counter to almost every best practice espoused by Brian and Bill. And I am adding to it.

The main difference with this application is that it will never be a public-facing internet application. It is intended to be deployed to a limited user base in an intranet/extranet environment. One of the overarching goals is to deliver sophisticated analytical tools and a desktop-like experience to the user community. So why not simply deliver a desktop application, or a series of extensions to ArcGIS, or both?

The answer to that is simply “enterprise IT policy.” This particular organization works under an IT policy framework that makes it nearly impossible to deploy custom desktop applications. This is not a unique situation as restrictive IT policies exist in many large organizations, especially Federal agencies. Some of that policy exists in the name of security, which is a laudable goal, but good developers with clear policy requirements, working in collaboration with IA staff, can secure an application regardless of how it is deployed. A larger driver is reduction of configuration management costs. It is simply expensive to identify specific users, ensure their systems meet proper specifications, deliver desktop tools to them, and sustain those tools over time. This, of course, has been one of advantages of web applications from the outset. So “stuffing the desktop into the browser” looks like an attractive path and it is for development that must meet requirements within a budget and a schedule. Anything that reduces the friction of dealing with IT policy is a win.

This is all well and good within the confines of one’s own intranet. What happens behind the firewall stays behind the firewall…except for when it doesn’t. Poor application design is poor application design regardless of which side of the firewall on which it sits. When draconian IT policy enshrines the adoption of something-less-than-best practices, we all lose. Groupthink begins to set in and developers that spend their time building plugin-based, should-be-desktop applications on the intranet for a targeted audience of GIS users can begin to lose perspective on what makes a suitable interface for the general user. Eventually, those intranet practices will begin to be exposed on public-facing applications because many developers will continue to do what they have learned (and have been encouraged) to do.

Any enterprise that is sufficiently large enough to have instituted a heavy IT policy is probably engaged in some level of software development and/or customization. That policy should be flexible enough to enable users and developers to choose the right tool and/or architecture for the job, rather than turning one particular architecture (HTTP in this case) into a one-size-fits-all channel for inappropriately designed tools and practices.

This is important because there are still an awful lot of .Net developers out there, especially in government shops that made a big Microsoft push in terms of infrastructure and training years ago. Of course, many of those shops are also committed to Esri technologies but SharpMap, while being a fully-functioning mapping/GIS library, also provides easy access to data sources not natively supported by Esri. Additionally, it is very easy to extend to support new or custom data sources and strightforward to get SharpMap to play nicely in traditionally Esri-centric environments.

At my company we’ve used SharpMap for just that for one of our key Navy customers. By building custom SharpMap data sources, we’ve been able to encapsulate business logic in Oracle, including the use of Oracle Spatial SQL to execute spatial analysis processes and deliver the results back to an Esri web client that is also interacting with ArcGIS Server for many standard functions. SharpMap enabled us to expose this logic through an HTTP+JSON interface while bypassing geodatabases, server object extensions, and other such cruft.

In recent years, other open-source .Net projects such as DotSpatial have gained traction and that’s good. The .Net environment remains in widespread use so it is useful to have open-source geospatial options for that platform. I’m happy to see SharpMap remaining an option in that space.

The preliminary program (PDF) for this year’s event looks exceptional, building upon and potentially exceeding the outstanding quality of FOSS4G-NA 2012. I’ll be sorry to miss the conference this year but will be looking forward to its social media exhaust.

_{^{Image by s shepherd schizoform on flickr CC-BY-2.0, via Wikimedia Commons}}

First, regarding the post ”A #LazyWeb Compendium of Python Resources for Beginners,” the University of South Florida PyBulls Python interest group, as promised, compiled a list of Python resources and posted it on their GitHub page. Thanks to them for their quick response.

Second, following up on the post ”The Best Thing I Saw at TUGIS 2013,” the data and workbooks for Dr. Arthur Lembo’s introduction to open-source GIS have been made available. The data can be found on GitHub and the workbooks can be found on the Eastern Shore Regional GIS Cooperative web site. Many thanks for contributing these resources.

These items are embedded in the comments for their respective posts but I thought it would be useful to call them out more prominently.

The photo below shows 40 participants of an “Introduction to Free and Open Source GIS Software” workshop getting hands-on experience with QGIS and PostGIS by working through prepared but realistic scenarios. These scenarios included doing multi-user editing and performing spatial analysis to assess the effects of a potential toxic release over a small town.

The workshop was put together by Dr. Arthur Lembo of Salisbury University and conducted by him and a team of his students, who not only led portions of the workshop but were also stationed around the room to provide guidance to participants. The scenarios were prepared in printed workbooks that the participants were free to take with them, along with information about how to download the tools. All-in-all, I thought the workshop was very well-designed and presented a thorough overview of the capabilities of these two tools.

To be sure, the workshop was not all unicorns and rainbows. There were typical glitches such as file system and database permission issues that required on-the-fly adjustments, which Dr. Lembo and his students handled well. Some participants were clearly stumped at points while others were making good headway with the examples.

Many of the participants probably remain committed ArcGIS users after the workshop while others may very well dig in and more thoroughly explore QGIS and PostGIS, but that’s really beside the point. Regardless of what the individual participants decide to do with the information from the workshop, all left with hands-on exposure to the tools that was presented in a manner that was free of hyperbole, FUD, or market-speak. They now have more first-hand information with which to make their own educated decisions as to how they want to proceed with their geospatial technology choices; and that, in my opinion, may have been the most valuable outcome of the workshop.

One thing I like about regional GIS conferences like this is that they tend to focus more on solutions to real-world problems instead of the latest technological bells and whistles. I spend so much of my time with my head in Federal requirements that it’s nice do a reset and get different perspectives on how geospatial technologies are used. I am particularly interested to hear the keynote from Learon Dalby of Sanborn and formerly of the Arkansas GIO office. I had the pleasure of working with Learon and the AGIO team on a project a couple of years ago and am impressed with what they accomplished.

I appreciate the new format of TUGIS as a one-day event is much easier to fit into the schedule. I’m looking forward to it.

I got a couple of requests to summarize any information I received, which seemed reasonable. I got quite a few responses and here are some links:

Learn Python the Hard Way - This one got the most mentions
Invent With Python
Green Tea Press
New Coder
Codecademy
Khan Academy
Dive Into Python - Note: I heard positive and negative on this one.
Real Python
MIT Introduction to Computer Science and Programming
Udacity

I can’t claim to have checked out all of them, but I consider the recommendations to have come from trusted sources. So, if you’re looking to expand your GIS expertise by adding some Python knowledge, these may be a good place to start. Not all of them are free-of-charge since that wasn’t one of my friend’s requirements.

Additionally, Dan Dye informs me that the PyBulls Python interest group at the University of South Florida will take up this question and post a document with a list of resources on GitHub. Be sure to keep an eye on https://github.com/pybulls/ . Thank you!

Many thanks to Hugo Estrada, Don Meltz, Aaron Burgess, Jason Sanford, Dan Dye, Christopher Moore, Shaun Walbridge, Jason Wheatley, Wes Herche, and Jorge Sanz.

If you have any other good online resources for getting started with Python, feel free to leave them in the comments.

While neither ArcMap nor Arc2Earth are open-source themselves, Jack points out that Arc2Earth acts as a bridge between ArcMap and several geospatial hosting platforms that are built on open-source technology but, also just as important, are successful at making data more openly available. These platforms include CartoDB and MapBox, among many others.

Many people use, and prefer, ArcMap has their desktop cartography and analysis tool. I view Arc2Earth as an enabling technology that allows users to continue to be productive with ArcMap while also allowing them to retain control of how they direct their GIS investments in terms of publishing and hosting their maps and data.

Disclaimer: My company is an Arc2Earth reseller.

1. There are a lot of analysts out there looking for jobs. Every time I run an ad, I get at least 100 resumes from people of various levels of experience and education.
2. The vast majority of those that I call to pre-screen have not done any meaningful coding of any kind. This includes Python, which has been shipping with ArcGIS for several versions now.
3. Of those that do have some coding experience, many do not show it on their resumes. I find this particularly interesting as I can’t imagine why a person would choose not to list all relevant skills or experience.

I am very publicly on the record that I think some form of coding skill is essential for any GIS analyst entering the workforce today. My reasoning here is fairly straightforward.

1. The “IS” in “GIS” stands for “information system.” This means “computers.” Actually, according to one of my professors in the late ’80s, an information system doesn’t technically have to involve computers but this is 2013 and even brewing a cup of coffee involves a computer.
2. The “G” in “GIS” stands for “geography.” (Don’t worry, the revelations will keep coming.) Geography is intensely mathematical. I suppose, in the interest of accuracy, I should state that some segments of geography are less mathematical than others but I think it’s safe to say that the elements of the science that are addressed by GIS involve a lot of math. Take, for instance, coordinate reference systems. That one small but important part of geography can separate the wheat from the chaff quickly.
3. Computers use code to do math.

Modern GIS software is complicated and comes with a lot of capability by default. Just look at the default UI for ArcMap or QGIS and you’ll see a lot of tools at your fingertips. In other words, there are a lot of buttons to push. This is fine but I’d wager that these software tools expose less than 10% of their full capability through their default interfaces.

The reason for that is that there are simply too many use cases in geography to design into a piece of software by default. That is why these tools, and most other GIS software, ship with APIs. (“Ship” is a loose concept with open-source but please grant me license.) These APIs expose the full capability of the software so that users may customize it to their needs. That means coding. For both ArcGIS and QGIS, that can mean Python but there are lots of other choices as well.

If you choose to get by with just using the GUI tools, you are doing yourself two disservices:

1. You are placing yourself at the mercy of others who can code to get around to building the customizations you need.
2. You are allowing your skills to erode by not using a significant amount of capability.

So you need to code to some extent. You need to in order to automate complicated tasks you do regularly, or read in data that’s in some oddball format, or use some capability of your GIS-du-jour that isn’t exposed out of the box, or to make that web map sing, or for any of a number of other reasons. Luckily, you have a wealth of information at your fingertips. It is called open-source geospatial software. I can already hear the protests: You learned on ArcGIS in school. You are comfortable with ArcGIS and you like it. Fine, keep using it.

But while you’re using ArcGIS, also check out the source code for open-source libraries like Shapely or GEOS or GDAL or other commonly used (even under the hood of ArcGIS) tools. You learned the math in school. You toughed out these concepts and you understand them. Now look at the compiled knowledge of a lot of smart programmers to see how the concepts are concretely implemented in code. The process will, at a minimum, make you a better ArcGIS user because you’ll understand what’s going on under the hood. The truth is, even if ArcGIS isn’t directly using one of those open-source libraries, it’s probably using an ESRI-developed implementation of a standard algorithm. It’s similar enough that you’ll be able to understand the behavior and that will help you better bind your own customizations to their closed-source API.

I say this because it worked for me. I am a programmer by training and passion. I heard the phrase “GIS” once, in passing, during a lecture in college. Yet, my first job was in the GIS field. Needless to say, I had a lot of learning to do. Most of it came at the hands of some very patient geographers. The first tools I was exposed to were the proprietary tools of MapInfo and ESRI (with a smattering of Intergraph). I was able to soak in what the geographers were telling me and bang against those APIs to build some useful tools but the light bulb really came on for me when I began reading the source code of open-source projects. There, laid out before me, was what the software was really doing.

Today, I work with a mixture of open-source and proprietary tools but the majority of my paying work is still in the Esri realm. My exposure to open-source has, however, made me better with it because it has deepened my understanding.

Not everyone can be a professional software developer as it takes a certain mindset to do it all of the time. But, in the GIS market of 2013, everyone needs to have some understanding of some kind of coding, whether Python or R or Javascript or something else.

One other side note: Over the past year, I have also advertised for software developers with results that are opposite of what I see with analysts. There are very few applicants and many that I see have been out of work for a while, have no GIS background and spent a lot of years working with older tools. These are “blue bird” applicants hoping to catch on. In short, there is a gulf between the high demand for GIS-literate programmers and the miniscule supply. Having the ability to code, and showing it on your resume, can be what separates you from the pack of 100 other analysts applying for the same position.

So, yes, you need to code.

The GDAL/OGR plug-in caught my attention because it purports to add support for any format supported by GDAL and OGR, similar to the way QGIS leverages them for a wide variety of format support. To get going with it, I downloaded the source and built it in Visual Studio 2010. I only ran into a couple of minor issues. First, a had previously installed the Windows build of OGR on my machine using the distribution from GIS Internals. The project as it came down from GitHub couldn’t find the OGR and OSR bindings for C#, so I had to resolve that trivial issue. Next, the plug-in was built for use in ArcGIS 10.1 but I was using 10.0. Because some new interfaces were introduced, the current code contains a declaration of type ISpatialReferenceFactory4, which is a 10.1 interface. I needed to change that to ISpatialReferenceFactory3 to make it work with 10.0. That has been the only change I have needed to make so far to account for the version differences. I plan to add a compiler directive in my fork of the project to account for that and submit it back once I can test it.

As I said before, I previously had installed GDAL/OGR so it was already on my machine and my GDAL_DATA environment variable was set. When I built the plug-in and attempted to use it in ArcMap, it threw an error when I tried adding a GeoJSON layer (also with SpatiaLite) that it could not find my gcs.csv file, which is in my GDAL_DATA location. With a little investigation, I found that the code was resetting that variable at runtime to point to the location of the plug-in binary. I copied the files there and it worked well from then on. I’ll probably try to add a way to check for the existence of that variable before setting it. None of these issues were major and I think they were reasonable design choices up front so I am not concerned by them.

At that point, I was able to quickly add GeoJSON and SpatiaLite layers to my data frame in ArcMap. This is pretty exciting to me since the ability to support a wide range of data types was a long-standing goal of zigGIS and I’m glad that Ragi has conquered that with this work.

Because the layers are added using a plug-in workspace, they are full read-only citizens inside ArcGIS. For example, I was able to wire up a couple of models using ModelBuilder and execute clips (clipping a GeoJSON layer with a SpatiaLite layer) and buffers and simple tests. I’m really not a huge ModelBuilder user but I thought it would be a good way to test things out.

Model to test a simple buffer

The model above produced a 50-foot buffer around Amtrak rail lines from NTAD 2012 in GeoJSON format. The resultant buffer was written to a file geodatabase. As you can see from the image below, it worked like a charm.

Results of the buffer model.

I achieved similar success with a clip operation so I’m sufficiently confident in trying to package the plug-in up and put it in the hands of some of the analysts with whom I work. All-in-all, the plug-in is a nice piece of work. It’s still not fully baked but it’s a very solid start and deserves a closer look if you’re looking to expand the reach of your ArcGIS investment.

What follows is an overview based on some of the notes I took. I wasn’t always writing as I sometimes just stopped to listen and I’ll probably follow up with more details later.

Data reduction was strong current running under the day. With the rise of newer libraries that enable more sophisticated capabilities in the browser, there is increased recognition of the need to reduce the amount of data passing over the wire. For geometry, TopoJSON is getting a lot of attention here. It delivers topologically correct data which reduces data by removing redundant geometry such coincident arcs between polygons and such. The output reminds me of an old ARC/INFO coverage and is providing stunning results in reducing the size of geometries when compared to GeoJSON or Esri JSON. Andrew Hill of Vizzuality mentioned that CartoDB currently has support for TopoJSON in staging. He also discussed strategies they use to reduce the size of feature and attribute data. This “data cubing” strategy turns out to similar to approaches that are commonplace in the financial industry. This serves as a reminder to look around and see what others are doing to solve similar problems.

One a related note, the reduction of application code being delivered to the browser is also a focus. This was probably best illustrated by Matt Priour’s talk on OpenLayers. The fact that there are now three builds (full, mobile, light) as well as a focus on being more modular in version 3. Peter Batty, in his demo of Ubisense, made a good case for intelligent balance between server-side and client-side processing to achieve good performance.

WebGL got a lot of attention from a number of speakers, with Brendan Kenny of Google showing work he has done, including a Javascript port of GLUTessellation. Jeremy Bartley of Esri gave a lightning talk about CityEngine, which is based on WebGL. WebGL is widely seen as the open solution to graphics performance that may finally kill the need for plug-ins. In side discussions, Jeremy talked about how WebGL will figure more into the previously discussed data reduction problem. The reality is that both servers and clients are getting much better at handling large data sets but the same can’t necessarily be said for the wires that connect them.

GeoJSON continues to get a lot of love. It continues to be, in my opinion, the motor oil for the engine that is web mapping. It will be interesting see how the separation of concerns between GeoJSON and TopoJSON evolves, but I think GeoJSON will continue to be an important syntax.

While the majority of the discussion focused on browsers, Node.js got significant attention. Will White of MapBox gave a good talk about the evolution of Node and the advantages of its non-blocking I/O model. One statistic he gave was surprising: he said 6 of the top 12 contributors on GitHub are Node contributors. That speaks loudly to the rapid evolution of Node as well as the interest in Javascript. Will put out a call to the geospatial community to build out the geospatial capabilities of Node. Later in the day, we saw a good lightning talk that showed Node processing real-time data and feeding a number of D3 visualizations.

While Matt Priour and Aaron Ogle opened with great talks on OpenLayers and Leaflet, respectively, the clear star of the client-side show was D3 (although Aaron’s walkshed analysis in Leaflet was cool). There were lots of great visualizations (as well as nods to TopoJSON). While the D3’s support for projections is getting a lot of attention from geospatial developers, I am more interested in its holistic approach to data visualization. In D3, geo is one way to look at data, but not the central way. Because of this, D3 provides an integrated capability to have multiple data visualizations in an application without overloading with a ton of libraries.

I am already well past tl;dr on this post and I have to catch a plane. Many of the URL talks were great but I’ll follow up with some more details. All-in-all, I think the event was quite a success and I’m glad I came.

• It calls out SQLite as the reference implementation of a GeoPackage container
• It calls out SpatiaLite 4 as the reference implementation of a vector feature store
• It does not call out a reference implementation for rasters or tiles
• It does not mention exchange of cartography.

Although the draft references the MBTiles specification and uses it as an example of a pure SQL method of storing tiles, it does not call out MBTiles as the chosen storage approach nor does it mention MBTiles as a reference implementation. The draft should not be read as “SpatiaLite + MBTiles.”

I think, in 2013, anything that attempts to do what GeoPackage sets out to do should have some provision for cartography. I would prefer CSS-like approach (such as CartoCSS) and will say so when I submit comments but I would suspect that future discussion of cartography, if any, will probably start with SLD. For now, tiles can fill the gap.

So comments are open, give it a look and tell OGC what you think.

The pace of innovation with Javascript in the geospatial area has been staggering. It seems like only a short time ago that the options for working with geospatial applications were OpenLayers and the Esri Javascript API. The rapid advent of tools such as GeoExt, Leaflet, and many others has really lead to a explosion of capability. Of course, the recent buzz has been about D3, which tackles a wide range of data visualization problems, including geo. D3 is of particular interest because it is tackling the issue of projection in the browser, freeing applications from the dominance of Web Mercator.

Of course, it’s not been all about the browser, either as Node.js has made abundantly clear. One of the most effective desktop applications for cartographic design, TileMill, is built with Node, among other tools.

The maturity of Javascript as a tool for geospatial development is such that I am at the point that, if it weren’t for government customers that are still standardized on Internet Explorer 8 or older, a plug-in-based environment would not be my first choice for a new application.

As for the JS.geo event itself, I am intrigued by its small, focused nature. It doesn’t seem to be as informal as an unconference but may be easier to digest than the typical geo event. It will also be great to catch up with the Front Range crowd.

More information about this update can be found here. Says Sandro:

The main goals of these recently introduced enhancements are:
- storing XML Documents directly within the DBMS
- supporting XML validation
- supporting plain SQL queries on behalf of XML Documents
via canonical XPath expressions

Implementing directly into the Spatial DBMS a common core of XML-oriented features surely is an interesting and useful option, just considering that ISO- and INSPIRE-Metadata or SLD/SE Styles are fully based on XML.

Although I find myself working more with GeoJSON and CartoCSS these days, I think support for XML is a good step for SpatiaLite. There are some very mature use cases based on XML, as Sandro points out. While SLD is not my favorite, this may keep it on my radar. Also, it would be interesting to see how this new capability would possibly affect the evolution of the OGC GeoPackage draft specification.

Data licensing has always been an important issue but seems to be moving to the forefront as demand for quality spatial data grows. This workshop could prove to be timely. It is being held on 24 January 2013 in Tysons Corner, VA. Details can be found on the Spatial Law and Policy blog.

Links to the old “geobabble.wordpress.com” URL will no longer automatically forward to “blog.geomusings.com”. Those links will go to the old Wordpress site, rather than the new location. While this may not be the worst thing in the world, I highly recommend updating any links you may have to point to this URL. I have taken pains to ensure that links using “blog.geomusings.com” redirect correctly but there may be some hiccups. If you notice issues with links to older posts, please feel free to contact me using the information on my “About” page and I’ll try to help resolve it.

Wordpress.com had perfectly justifiable restrictions on what you could do with a blog (no embedded Javascript, for instance). Over time, I began to feel those limitations more and more. I had originally just planned to move to a self-hosted Wordpress site but I began to reconsider that earlier this year. A couple of blogs I follow were running on Octopress/Jekyll and I was impressed with the performance of the static content. Additionally, I decided I wanted to use a platform that could help stretch me as a programmer. I was not particularly interested in becoming more proficient at PHP (Wordpress) but I was interested in getting more comfortable with Ruby (Octopress/Jekyll), as well as Javascript and CSS.

There were other considerations but I won’t belabour the point. Thanks for your continued support and please update any links that you may still have pointing to the old “geobabble” URL.

While I’m looking forward to seeing how James evolves Planet Geospatial, there are ways to more efficiently extract value out of its current state right now. At its core, Planet Geospatial is an RSS feed. RSS can safely be called “venerable” nowadays, but it still does what it does very well.

Two of my favorite tools for culling down the firehose that is Planet Geospatial are IFTTT (the title of this post is a riff on the IFTTT motto) and Evernote. If you’re not familiar with IFTTT, you should be. It reminds me of a more-intuitive Yahoo Pipes and it allows you to mix channels, triggers, and actions to automate processes of your choosing. It’s become by preferred method of synchronizing my blog with social media and for filtering data sources. It also drives the Unofficial QGIS Info Twitter account.

Evernote is becoming a key tool for me to store and access notes and other kinds of information. The fact that it runs on every device I own in addition to browsers makes it very useful for me as I move between customer locations.

When James first posted that he was wondering what to do with Planet Geospatial, I shared with him an IFTTT recipe that inserts posts from Planet Geospatial about PostGIS into an Evernote notebook. He kindly tweeted it.

I usually have three to four such filters running, depending upon topics that I’m watching. Currently, I’m grabbing posts about PostGIS, GeoJSON, and CartoCSS. These filters allow me to peruse the posts at my leisure without worrying about missing them. I can delete them from my notebook or save them as I see fit. For me, it’s like having a DVR for Planet Geospatial.

Ultimately, Planet Geospatial is an information source. It just happens to be an information source that’s based on a mature, open, well-documented, and widely adopted standard. As such, there’s no need to wait for James to evolve it into something else. We can take it and transform it to meet our needs and then share it back. It’s been a great community resource for a long time; it will be fun to see what the community can do with it.

I am happy to see that this version was developed and contributed back by the US Army Geospatial Center. The fact that they contributed back to the project under a standard open-source license is a nice step from a DoD organization.

The message is quoted below:

Hi List, I’m really proud to announce you all that finally a rock solid stable and really easy-to-be-deployed binary porting of SpatiaLite for the Android platform is now available for download [1]. [1] https://www.gaia-gis.it/fossil/libspatialite/wiki?name=splite-android Many thanks to the U.S. Army Geospatial Center [2] who very generously contributed this highly appreciated and really useful resource under a genuine free software license (LGPLv3). [2] http://www.agc.army.mil/ A detailed tutorial [3] explaining how-to deploy and use SpatiaLite on Android platforms has been kindly contributed by Andrea Antonello, who spent many long hours during the last week while performing a thorough testing of SpatiaLite-Android, then deciding to publicly share his experiences with the SpatiaLite community. Feel absolutely free to pay a beer to Andrea; he’ll surely appreciate ;-) [3] https://www.gaia-gis.it/fossil/libspatialite/wiki?name=spatialite-android-tutorial enjoy, Sandro

Not this SpatiaLite

I have a couple of Federal customers that are integrating SpatiaLite into their workflows so I’ll need to take a day or so to assess impacts any impacts there. Looks like the perfect way to slide back into work after a long weekend.