I've made a new version of the URI redirection engine that runs in Django (see the original post here). The tool allows you to provide a list of URI patterns that identify specific resources, and redirect traffic that matches that pattern to a URL where a representation of the resource exists. It allows for content-negotiation, and the new version also begins to build infrastructure by which various instances of the application can communicate with each other.
Each instance of the application is informed about the existence of various registers, which are essentially sets of URIs. The application may or may not know how to resolve URIs that are a part of any given register, but can send incoming requests to others servers capable of resolving that register's URIs.
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!
sudo apt-get install python-pygresql
Here are a few screenshots to give a taste of what it is like to use our new Django app to manage a set of URI redirections:
For any URI-Scheme: Basically, the Django app allows you to control a listing of MIME Media Types, and Rewrite rules.
USGIN URI-Scheme: The same basic structure, but the USGIN-specific app allows you to control a listing of Name Authorities and Resource Types, as described in this post.
Listing of Rewrite Rules: A nice overview of what rewrite rules you have in place, and a mechanism for searching for the one you might need to adjust.
Creation of a Rewrite Rule:
I'm relatively new to Django, and maybe to servers in general, but setting up Django is a chore. Or at least figuring out how to set it up is. There is no installer. You have to have a pretty good understanding of how your HTTP server (IIS, Apache, whatever) works before you're going to be able to get anywhere. Then you'll have to know how to set up quite a few ancillary applications (e.g. Python, WSGI, FastCGI, Flup, MySQL, PostgreSQL). The details of which other applications you want to set up depend entirely on the evironment you're building - so that means it is a little different every time - and that means it is pretty hard to write one single "walkthrough" for how you should do it.
What I want to do here is detail my setup, and along the way make some suggestions about what seems to make things easier. So here goes:
Suggestion: Use Ubuntu (Most recent stable version, always.)
I say this because that apt system really makes installations a breeze. I fumbled for a while to try and setup WSGI (a module for Apache) to work on my Windows machine, to no avail. In Ubuntu it is so easy:
Thought and ideas about using Django to accomplish USGIN-related... things.
I am currently using Pylint to check for bugs and formatting errors in my Python scripts. I used Brandon Corfman's nice Komodo Hacks: Integrating Pylint tutorial to set up Pylint and how to integrate it with the Komodo Edit IDE (see Easy setup of a Python 2.6 development environment on Windows about setting up Python).
Here is my updated Pylint execution macro for Komodo Edit 5 which includes a verbose and an errors only reporting command.
Converting FGDC XML metadata records for WMS and WFS services to ISO 19139 via Python and GeoNetwork
This post describes a series of Python scripts to convert FGDC XML metadata for WMS and WFS services to ISO 19139 service metadata via GeoNetwork's OGC harvest service. Here are the steps:
- Extract WMS and WFS GetCapabilities URLs from FGDC XML metadata and write them to a file.
- Create a GeoNetwork Harvest Node from extracted GetCapabilities URLs and let GeoNetwork's OGC WMS/WFS harvester create ISO 19139 metadata from GetCapabilities response. Note: the resulting ISO 19139 metadata is only as good as the one in the GetCapabilities response. In addition, GetCapabilities responses do not include all fields necessary for minimum ISO 19139 metadata.
- Copy some FGDC metadata entries (Title, Abstract, etc.) to newly created ISO 19139 metadata.
Our goal is to have working WMS and WFS metadata records in our CSW catalog that can be used to add the described services to analytical software such as ESRI's C-SW Client for ArcGIS Desktop. Following are the reasons why I am currently choosing this convoluted process instead of a direct FGDC to ISO 19139 metadata conversion:
This is an example script on how to do XSLT transformations in Python 2.6 through the Gnome libxml XML C parser and toolkit. The relative fast C library is available on multiple platforms but you will also need Python bindings for libxml2 and libxslt. There is a handy libxml2 and libxslt Python bindings installer for Windows which also includes the C libraries in DLL form.