diff --git a/resources/public/content/Data on maps.md b/resources/public/content/Data on maps.md index 96fc3bf..475c662 100644 --- a/resources/public/content/Data on maps.md +++ b/resources/public/content/Data on maps.md @@ -8,10 +8,10 @@ So there were clear routes to several of the parts of this problem: 2. If you want a spreadsheet that is live on the Internet, [Google Sheets](https://developers.google.com/sheets) are a very good way to go; 3. Google Sheets allows export as Comma-Separated Values, and CSV is a very easy format to parse. -I needed to do this quickly, so I started in my comfort zone, using Dmitri Sotnikov's [Luminus](framework) and mixing in the [Day8 re-frame](https://github.com/day8/re-frame) framework, in order to have a lot of built-in functionality client side. The joy of the [Clojure](https://clojure.org/) development tools is that getting a working system is as easy as typing +I needed to do this quickly, so I started in my comfort zone, using Dmitri Sotnikov's [Luminus framework](https://luminusweb.com/) and mixing in the [Day8 re-frame](https://github.com/day8/re-frame) framework, in order to have a lot of built-in functionality client side. The joy of the [Clojure](https://clojure.org/) development tools is that getting a working system is as easy as typing lein new luminus geocsv +re-frame - + And from that point on you can do your development with your system live, and can see the effects of every change you make immediately. So within a couple of days I had a polished wee system which looked good and pulled live data from a Google Sheets spreadsheet to populate a map, with different graphical pins for her different classes of records. It was highly reusable, since you can specify the document id of any public Google sheet in the query part of the URL, and that sheet will be rendered. The map automatically pans and zooms to focus on the data provided. Was I pleased? Well, sort of. @@ -50,6 +50,6 @@ All three variants have merits. The first pulls the data directly from Google Sh ## One more time with feeling -One of the reasons why I get hammering at this problem was that I felt it would make a really useful extension for my wiki engine, [Smeagol](https://github.com/journeyman-cc/smeagol). I've integrated the JavaScript version, geocsv-js, and in doing that I've solved a number of problems. Firstly, the look and feel and content of Smeagol pages is flexible and easily configurable by the user, so it doesn't take a geek to set up a page with the content you want and a map of the data you want to show. Secondly, the Smeagol engine, because it sits server side, can pull data from remote sites, and because it doesn't interpret that data, there's no significant risk in doing that. Thirdly, again because it sits server side, it can deal with the issue of unknown images - and, because it's a wiki engine targeting less technical users, I've deliberately made it very graceful about how it does this. +One of the reasons why I kept on hammering at this problem was that I felt it would make a really useful extension for my wiki engine, [Smeagol](https://github.com/journeyman-cc/smeagol). I've integrated the JavaScript version, geocsv-js, and in doing that I've solved a number of problems. Firstly, the look and feel and content of Smeagol pages is flexible and easily configurable by the user, so it doesn't take a geek to set up a page with the content you want and a map of the data you want to show. Secondly, the Smeagol engine, because it sits server side, can pull data from remote sites, and because it doesn't interpret that data, there's no significant risk in doing that. Thirdly, again because it sits server side, it can deal with the issue of unknown images - and, because it's a wiki engine targeting less technical users, I've deliberately made it very graceful about how it does this. -So now, instead of just a map on a web page, you get a whole, richly editable website, with existing extensions to integrate sophisticated data visualisation and photograph galleries as well as maps. And the cost of this? Surprisingly little more. A Smeagol page with one map uses exactly the same memory on the client as a geocsv-js page with one map, because Smeagol now only loads JavaScript for extensions actually being used in the page, and almost all of its own functionality runs server side. But even server side, the cost is not very much greater than for the full fat geocsv implementation - the deliverable jar file, which offers far more functionality than geocsv, is only 88 megabytes. Considering how much more usability and flexibility this offers, this is the version of geocsv I'd now offer, if someone came to me with the same problem. \ No newline at end of file +So now, instead of just a map on a web page, you get a whole, richly editable website, with existing extensions to integrate sophisticated data visualisation and photograph galleries as well as maps. And the cost of this? Surprisingly little more. A Smeagol page with one map uses exactly the same memory on the client as a geocsv-js page with one map, because Smeagol now only loads JavaScript for extensions actually being used in the page, and almost all of its own functionality runs server side. But even server side, the cost is not very much greater than for the full fat geocsv implementation - the deliverable jar file, which offers far more functionality than geocsv, is only 88 megabytes. Considering how much more usability and flexibility this offers, this is the version of geocsv I'd now offer, if someone came to me with the same problem.