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
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.
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.
and set the refresh parameters to fly-based refresh after â€œ4 secsâ€
7. Assuming all went ok, you should now have a feature for each polygon which can be toggled individually.
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.
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.
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.
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.
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.
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,
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.
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)
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?
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?
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.
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)
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.