Leaflet is a simple javascript framework for building web-mapping applications. In thier words:

Leaflet is a modern, lightweight open-source JavaScript library for mobile-friendly interactive maps. It is developed by CloudMade to form the core of its next generation JavaScript API. Weighing just about 21kb of gzipped JS code, it still has all the features you will ever need for your web mapping needs, while providing a fast, smooth, pleasant user experience.

It is built from the ground up to work efficiently and smoothly on both desktop and mobile platforms like iOS and Android, utilizing cutting-edge technologies included in HTML5 and CSS3. The focus is on usability, performance, small size, A-grade browser support, flexibility and an easy-to-use API. The OOP-based code of the library is designed to be modular, extensible and very easy to understand.

When you're choosing a javascript framework to build your web-mapping application, you have a myriad of options. Why choose Leaflet? Well this is why I liked it:

Introduction

This is a scenario for a generic metadata edit tool, intended for brainstorming development of a community component that is transportable and reusable. Use of a standardized tool for editing metadata will reduce the cost of entry into the metadata game by reducing training and increasing productivity, and should help improve the quality and consistency of metadata.  The attached word document has the same text. Please add any other features or requirements that would be useful.

Here is a run down of some functionality.

The Scenario

Start: User opens the editor application.

Outline: Background; Approach: Metadata, Services, Interchange formats; Current status; Architecture and artifacts; Way forward

We can all agree that search engines like Google have really defined the way that we search for information on the internet. So the question is, why aren't we using Google to search for our geologic datasets? Do we have to do all that formal, structured metadata? What the hell is CSW anyways?

As an experiment, I built a new site: metadata.usgin.org. This site is buit with Node.js, a really cool way to build a web server by running server-side javascript code. Its so easy. Here's my code. So what does it do?

It acts as a proxy server. You ask it for http://metadata.usgin.org/record/a386a4ba-e892-11e0-9e4a-0024e880c1d2, and it reads that file identifier out and issues a CSW GetRecordByID request to a CSW server. The response to that CSW request is an XML document, and nobody (including Google) really cares about that, so the server formats the record as a very simple HTML page.

FYI-- this is a draft profile against the upcoming revision of ISO19115 for metadata, scoped to energy industry, but the scope overlaps requirements for USGIN (I've been very active in developing profile and looked after that).  Please have a look at the docs if you're interested in metadata. Given the standards process time lines, it probably won't directly impact us until next year.

steve

******************************************

Imagine that you collected geographic data in one schema and you want to provide it in some other schema. For many of us, this only happens pretty much all of the time.

For example, maybe your organization has an enterprise database which stores all the information that you have about recent, active faults. Now you want to provide that data as a WFS service with fields that conform to the ActiveFaults template being used by the AASG Geothermal Data System. Perhaps you store all your geologic map data in such a database and you want to convert it into FeatureClasses that fit into NCGMP09-style geodatabases.

Here's a nice way to convert your data formats in such a way that you only have to do it once. You can continue to make changes to your data just like you always have, and there will always be a featureclass hanging out there in the new schema which conveys the most up-to-date information that you have. The pre-requisites are:

There could be a number of reasons why you'd like to use a database view as a backend for a WFS. Perhaps your data is split across multiple tables and updated regularly. Perhaps the data is in a table without an explicit ESRI-style SHAPE field. That's the case in this example, where the geometry information is stored in a table as UTM coordinates.

ESRI's Geoportal metadata record editing has some validity checking, but error checking does not occur until after a metadata record form is submitted.  This can be a wasteful process because it involves having the client (the web browser) send a full request to the application server.  If the submitted form has data validity errors then the whole form is transmitted back to the client for editing.  One way to save the use of server resources (e.g., bandwidth) is by using jQuery to monitor information typed in html input boxes and check value validity before submitting the form.  Since, ESRI's Geoportal comes with jQuery already enabled it is relatively to add validity checks.  The first thing to do is create a custom javascript file (e.g. [geoportal_install_dir]/web/geoportal/catalog/js/custom.js).  The contents of my script are:

$(document).ready(function()

{
  $('#mdEditor\\:identification_date').mask('9999-99-99T99:99:99');
  $('#mdEditor\\:general_datestamp').mask('9999-99-99');     

PyGreSQL is a python library that allows you to write python code to interact with a PostgreSQL database. I can see some utility here if I start wanting to write Django methods that do things like create views of some of my tables.

May be useful in not too long! Don't forget about it!

Documentation: http://pygresql.org/pg.html

Installation:

sudo apt-get install python-pygresql

Use: