FeatureServer and OpenLayers information

FeatureServer is an implementation of a RESTful Geographic Feature Service. Using standard HTTP methods, you can fetch a representation of a feature or a collection of features, add new data to the service, or delete data from the service. Use it as an aggregator -- post your GeoRSS feeds to it, and then browse them using WFS. Use it as a translator: use the OGR DataSource to load a shapefile and open it in Google Earth.

This software also is able to use a PostGIS as it's storage and information mechanism. In addition to this, there are several options for input/output:

• GeoJSON -- input and output in the emerging GeoJSON specification. FeatureServer supports GeoJSON Points, Lines, and Polygons with Rings, as both input and output.

• GeoRSS Atom (Simple) -- input and output of Points/Lines/Polygons (no rings/holes) in GeoRSS Simple (Atom). This allows one to take any GeoRSS Simple Atom feed and feed it to FeatureServer for storage.
• KML -- Input and output of Points, Lines, and Polygons from KML.
• GML/WFS -- Output-only support of WFS/GML.
• HTML -- Output-only support of features as HTML files, powered by Cheetah templates.
• OSM -- Output-only support of features as OpenStreetMap '.osm' files. (These files can be opened using JOSM and posted to the OSM server.)

Since the iPhone is very capable of reading the JSON data format and it is very useful for tabular data. I have already discusses using JSON earlier in the semester with Robert Kosara and he seems to think that it would be a very efficient and easy way to transfer data to the iPhone. Plus there are several programs available that read data from JSON for the iPhone, such as TouchJSON which can be found at this link: http://code.google.com/p/touchcode/.

As soon as I am able to get a test machine up and running with the new version of Postgresql I will be able to install these things and test them out. Then we can begin developing methods to transfer this information over to a format that will be displayed properly on an iPhone.

The image below shows the framework of the featureserver and the many storage and input/output options:

Project Progress update 1/24/2009

This week I have been able to acquire the CAD data files for the College of Education at UNCC. I have been through the process of "cleaning" up these data files for use in our database and for our automation program. This process allowed me to delete and filter out all polygons and other bits of data that were either erroneous or not useful. After this was finished I was able to take each floor and geo-reference it to the base map in order to put it in the correct coordinate system for this project.

The current building files are now located in our GIS database as spatial data files that have been converted from shapefiles. They are now in the proper format to be read by Jianfei's automated centerline program to make paths inside the building.

Other things that have been done are: setting up and test the new version of Postgresql on my Windows box. This has allowed me to install the pgPhoneHome iPhone web application that will allow us to mainipulate our database from the iPhone. This will hopefully provide a first step in our mobile application.

I have also come across a useful project called FeatureServer. It is basically a implementation of a RESTful Geographic Information feature service. I will be posting more information about this service and all of the details in a later blog post.

Centerline Extraction for Convex Polygons

Jianfei has been working on the center line extraction for polygons which will serve as the routes in our building files. This will hopefully allow us to fully automate the pathways creation inside of buildings if we are able to accoplish the automation effectively.

From email from Jianfei Liu on January 21st, 2009:

I extracted centerlines from convex polygons this week. Snapshots are some results. For the concave polygon, it just needs a little extension to my existing framework. The current framework can handle certain concave cases except for one situation I neglected. I decided to design a more robust evaluation model to determine the polygon's type. In the results, the sphere means the vanishing point and the centerline is represented as the yellow line. In certain cases, the centerline is just one point.

Below are the snapshots from the centerline extraction from the above email: