Various OSS GIS news

Few things hit my inbox this week that caused me delight. So for all of you which aren’t signed up to the various mailing lists … here we go.

1. Geoserver 1.3 final has been released.

This release brings a number of improvements to make GeoServer the easiest way to get a powerful open source standards-based web mapping solution up and running quickly. GeoServer has traditionally focused on WFS, which allows access to the raw vector data, serving as the WFS reference implementation. 1.3 brings fully compliant WMS and SLD, which handle the rendering and styling of maps, available as JPEG, PNG, GIF, SVG and KML. Official OGC certifications are in the works for both WMS and WFS, as all compliance tests have
been passed.

For a full changelog see this page. I have only used it quickly, but there is some definate rendering improvements in both the speed and the output. Well done guys.

2. The FOSS4G2006 conference site has been released. Some good info available here for anyone who is interested. It really is the place to be for anything opensource GIS … such a shame Switzerland is so, so far away from Perth :(

3. Howard Butler has been busy compiling a build kit for compiling Mapserver source on windows. I haven’t tried this sucker yet, but if it solves 90% of people’s questions about “how do i compile ms?” then im a happy camper :)

It is a single zip that you can unpack and compile with a single “make”. It requires MSVC 7.1 (VS.NET 2003)
There are configuration option for SDE, PostGIS and Oracle Spatial and all the others in the nmake.opt file.

Torrents and Direct Downloads:
http://nasa1.us.archive.org/mapserver-4.8-msvc71-build-kit.zip
http://madmappers.freeearthfoundation.com/mapserver-4.8-msvc71-build-kit.zip

http://nasa1.us.archive.org/mapserver-4.8-msvc71-build-kit.zip.torrent
http://madmappers.freeearthfoundation.com/mapserver-4.8-msvc71-build-kit.zip.torrent

Calling all ArcMap gurus

In urgent need of some help here guys :)

My situation:

I need to join a SDE table to a local DBF file and you would think this is a piece of cake ..

SDE REGISTER_NO (CHAR(13)) -to-> DBF REG_NO (CHAR(13))

… the problem is that Oracle allows the CHAR(13) field to contain a space at the end of the field … dbf as far as i can tell, does not.

so I have something like

SDE :: ‘ 0217400624 ‘ trying to join to
DBF :: ‘ 0217400624′

which of course, produces no results.

I do not have access to SDE to create a temporary VIEW to change the SDE format, so i am limited to

  • somehow making ArcMap append the space to each record before doing the join
  • somehow forcing the DBF to stop right trimming the space or
  • somehow doing a partial match in ArcMap

Proper SQL tools please!!

If anyone knows how to do this with ArcObjects or any other method, PLEASE let me know as i am hoping i am just missing something obvious.

arghh

Geoserver KML output

As mentioned a while back, Geoserver had some experimental code for KML output. The latest PR1 release has vastly improved KML support, largely submitted by James MacGill.

There was a recent question on the GS-Users list about how to use the sucker inside Google Earth. My personal preference is still for WMS overlays, but if for some reason you’d like your live data outputted as KML, read on.

1. First things first, grab the PR1 release.

2. Setup your desired datastore using the GS web interface. In my case i will configure a new ArcSDE datastore.

3. Add your new featuretype, making sure you set the SRS as 4326 and generate the corresponding bounding box.

Featuretype config

4. Do the old Apply/Save/Load trick to load your changes.

5. Now our data is ready to go, we better check KML output is supported. Send a WMS (yes, WMS) GetCapabilities to your service and check that you have the following,


image/png
image/jpeg
image/svg+XML
image/gif
application/vnd.google-earth.kml+XML

6. We’re almost done. Now all we need to do is setup a corresponding network link to point to the “KML document” (which is in fact, just a WMS call to the KML output format).

Add the following in the location box for a new network link,

http://localhost:8080/geoserverpr1/wms?service=WMS&version=1.0.0&request=GetMap&format=application/vnd.google-earth.kml+XML&width=500&height=500&srs=EPSG:4326&layers=topp:lga&styles=green

and set the refresh parameters to fly-based refresh after “4 secs”

Refresh params

7. Assuming all went ok, you should now have a feature for each polygon which can be toggled individually.

Final

If you are feeling lucky, try adding label definitions and view scales to your SLD. Otherwise you may be unintentially trying to retrieve a KML file containing your whole road dataset :)

Be aware that due to the way GS extracts each feature, the polygon extents can and will extend beyond the requested BBOX, which can be a good or a bad thing i guess.

Things that could well be added in the future: KMZ support, more customisable KML output (such as Z/height attributes) … the list goes on. The flexibility in using the available Geoserver datastores certainly makes this a viable alternative to using the 100 different “arc exporters”. You just can’t beat live data getting sucked straight from your database

If this article interests you, please swing by the GS-Users list and say gday, they are always keen to get more contributors on board.

Adding routing overlays to kamap

Finally, my promised follow up to my build your own routing solution article. For those who have had success massaging their data to work the pgdjikstra module, lets rock and roll. I’m writing this on the fly so hopefully by the end we can get a usable, user-friendly routing solution into Kamap.

1. Kamap install.

Grab the latest stable (or CVS if you’re feeling lucky) release and follow the instructions to get it up an running. Paul and the rest of the crew have made this possibly the easiest frontend to get up and running in a flash, but if you do run into problems please contact the list.

Ignore my setup / mess, this was an existing mapfile used for benchmarks. This is possibly what you shouldn’t have setup, but its got the road centrelines so it’ll do for our purposes.
kamap

2. Create a database handler

Since we would like the users to be able to interface with our db, we need to create a little interface to query the roads and execute the shortest_path_as_geometry call. For the sake of simplicity, the following should give you somewhere to start. (Source: querydb.php, if the output below gets munged)

Dont worry if the output format doesnt really make much sense at the moment, we’ll touch on this in the next step.

< ?php
//SQL query
$query = "SELECT astext(the_geom) FROM shortest_path_as_geometry('roads', ".$start.", ".$end.");";
$result = pg_query($query) or die('Query failed: ' . pg_last_error()); // output
echo "n";
echo "n";
echo "	

3. Integrating PG’s kaXmlOverlay code

PG has done some great work looking into how best to integrate vector overlays on kamap, much like google maps does. Technically, there are lots of different options, but PG’s latest code uses a mix of the wz_jsgraphics and the PHP GD library.

This option has arguably the best cross browser support in that the route is actually rendered and thus positioned, as a PNG/gif image. But more on that later.

PG has posted a demo of the capabilities at his site (http://sistel.dyndns.info/ka-map/indext.html).

You will need to download the kaXmlOverlay.js, drawGeom.php and the wz_jsgraphics library.

Edit your existing kamap index.html and add,

The code is pretty self explanatory, we simply define the path to the XML (querydb.php) and attach it to the map initialised handler. PG has a slightly alternative setup on his demo website, adding a refresh function to automatically refresh the XML doc at a set period. This is a real handy feature if you’re tracking a live GPS feed, but in our case it just adds extra overhead.

4. Time to test

Since the code contains a few point of failures its best to start at the beginning,

  1. Chose a start and end edge id from your postgis table and try running http://your.host/kamap/querydb.php?ST=startid&EN=endid. You should get a well formatted text/xml response with the routing coordinates. If the edge ids dont exist or the geometry function did not work, you will get an error here.
  2. Now you have determined that you have got the coords, time to try kamap. Load up the modified index from step #3 and tail the apache logs. Amongst all the js queries, there should be one eventual request for the querydb, and then for the drawgeom (something like drawgeom.php?gt=L&st=5&bp=5&sc=25&cl=15,1800,0..). If after 30 seconds or so you dont appear to see any overlays, strip out the exact request from your log and try to run it in isolation. eg. http://localhost/kamap/drawgeom.php?gt=L&st=5&bp=5&… if GD is configured properly you should get an image output like below (PNG)
  3. gdoutput.png

  4. If its still not working, there probably just a URL thats throwing a 404. Keep checking the logs for what its requesting just to make sure its not trying to find a file in / and not /kamap

5. The result

Apologies in advance as i just didnt have time to implement a more dynamic approach such as a user entering a start/end address. I hope someone else out there has the time and the inclination to extend this stuff. The possiblities are endless.

6. Problems and future additions?

  1. Needs a better way of converting geo2pix. The existing js function has meant that potentially you could have 40 + coordinate pairs being converted (DB->XML->JS->Drawgeom->Image) to pixel space, and then passed via a URL parameter to drawgeom.php. Very inefficient, and can also go beyond the URL size limit … maybe short term the use of POST might be more suitable?
  2. Line simplification. Further work needs to see how suitable the PostGIS simplify() function is. Conceptually, a function to guesstimate a suitable tolerance for the zoom level, and then retrieve the new coords would be suitable but how easy at guessing said tolerance would be interesting.
  3. JS bloat. I’d prefer to move as much code as possible server side, especially for “calculations”. Being able to pass the current client params such as pixel/cell size, coords, scale etc. would mean much of the xmlOverlay.js code done by PG could be done server side, and potentially drawn in the same thread (eg. no need for a separate drawgeom.php … the initial query would pass the results direct)
  4. An extension to the current querying abilities, where users can click on the map for their start and end points, and the click points would be translated into geo and then fed back into a postgis function to grab the closest road edge. This was what i wanted to do for this article, but alas theres never time.