Chris Holmes from the Open Planning Project has published a TileCache tutorial on Codehaus. The tutorial covers installation, configuration, integration with OpenLayers, performance tuning, and cache seeding, making it a more in-depth complement to Christopher Schmidt’s recent screencap video. We hope you find it helpful!
Getting started with MapServer can be a daunting task. There’s a magical configuration file that’s non-intuitive to edit, and a lot of knowledge of things like projections and so on is required to edit the configuration files for anything but the most trivial data. One of the ways I’ve tried to help this has been distributing mapfiles for maps I create so that people can learn from them, but there’s only so much this helps alleviate the pain of learning the mapfile syntax.
This is the reason why I was extremely excited to see QGIS’s support for converting a QGIS project to a map file. Finally, something that could take the headache out of creating mapfiles by hand. Perhaps this could help create the GUI that users needed to create the maps they wanted, and get them onto the web.
Today, I put together a 4 minute video demonstrating exactly this functionality. It shows how to download GIS data, open it in QGIS, style it according to an attribute, and export that view to a map file. It then shows how to load that map file into OpenLayers, so you can view it in the browser.
You can view the video online at OpenLayers: Mapping Your Data (requires Flash), and the wiki page that goes along with it in the OpenLayers Trac: MappingYourData.
Questions, comments, and suggestions are always welcome.
— Christopher Schmidt, Video Maven
From an update I sent to the OpenLayers mailing list on the vector work we’ve done this week:
- Changed:
- Feature.js -> Feature.Vector. There are now two features — onedesigned for use with Markers, popups, etc. and one designed foruse with geometries.
- Parser/Writer classes now in a single ‘Format’, which has read()and write() functions which switch between strings and collectionsof features. This means that ot create a layer which is like theGML layer (accept a URL, put features on the map) but which parses, for example, GeoRSS, requires only writing a Format() classfor it, and then changing a single line of code.
This also means that it is possible to take any vector layer andserialize it to GML with a single function call. (var g = newOpenLayers.Format.GML(); gml = g.write(layer.features);)
- Layer.GML and Layer.WFS now use the Format class.
- Major changes:
- Attributes() parsing moved into the Format() class. This makes iteasier for other formats, but may be a performance hit. (However, Ihave run one hundred features through the GML parser and not hadany speed problems: the speed problems are typically in renderingrather than raw XML parsing). This means that feature.attributes isnow just a dict, rather than an object with an XMLNode attached.This means that all attribute parsing is done in one location,which makes it much simpler across the code.
- Style.js is going away. Instead, there is anOpenLayers.Feature.Vector.defaultStyle (similar toOpenLayers.Marker.defaultMarker) which encapsulates the defaultstyle: various other styles will be stored where appropriate,usually in the controls.
- MouseListeners seemed to boil down into a concept of ‘handlers’: there are several types of events on the map which should be encapsulatedin handlers which have various actions. (”draw box”, “draw point”,etc.) So, there are now ‘handlers’ which handle the action ofdrawing a point. Controls can then turn these handlers on and off:this will allow trivial building of controls like the toolbar,because each handler has an idea of whether it is activated ordeactivated, a toolbar only needs to encapsulate mechanisms forturning these functions on and off.
http://dev.openlayers.org/sandbox/vector-2.4/examples/draw-point.html
Checking the box turns the point drawing control on. Uncheckint it turns it off.
This also changes the ‘box’ mechanism such that you can easily tkaea box and do whatevery ou want with it. Handlers return the featurethat was drawn with them, essentially: so when you draw a pointwith the DrawPoint handler, it returns the point. When you draw abox with the zoombox handler, it reutrns the box.
If you look at the source of:
http://dev.openlayers.org/sandbox/vector-2.4/examples/custom-control.html
You can see the draw() of the control creates a ‘Box’ Handler(Handler.Box), and assigns the ‘done’ callback to call notice().This means that when the Box handler is done with drawing the box,it will call the notice function — with the bounds of the box. Thecontrol can then do what it wants with this. In some cases, (mousedefaults) this might be to zoom to the bounds described by thatbox. In this case, it just ‘alert()’s the pixel coordinates of thebox.
This solves a whole host of ‘how do I change the behavior of’questions: it encapsulates the Handling of mouse events at a lowerlevel than registering on the map, and the result is that somewhathacky code (like that in MouseDefaults) moves down a level, makingwhat MouseDefaults will soon be a very simple control which justsets up a set of handlers.
- Testing:
- Currently, the geometry classes have more than 150 tests. Erik hasdone an excellent review of these classes, and has pronounced themcomplete… I think
- Renderer, Format and Layer tests are coming up the pipeline.
- Documentation
- The planned route for API documentation is JSDoc, and the JSDoccomments have been kept together for most of the code (though a fewclasses that I wrote need better docs
)
- There are examples demonstrating how to add simple features tolayers, and that API is unlikely to change. Very little API changehas happened at all betweeen the vector and vector-2.4 branch, soif you were using one, you should be fine with the final versionthat goes to trunk.
- Future plans:
The desire is to get this stuff as done as possible this week suchthat we can walk away from the Cambridge OpenLayers Hackathon witha working branch, and hten soon after, merge it to trunk. We arehoping to get everyone on board for a 2.4 release in the next 2weeks with vector stuff — even if some features and functionalityare not complete — so long as there is a consensus that theexisting API is solid and unlikely to change. This will leteveryone work on continuing development of the vector code on trunkrather than on a branch.
I just want to offer a huge thank you to all the people who have madethis possible. The work on the vector branch is the only thing that hasmade this development possible, and a lot of people took part inmaking that happen. Camptocamp’s participation especially took this codefrom being a great idea to being a great tool. The vector branch is acore example of the widespread diversity of the Open Source communityparticipation that has led OpenLayers to become such a great project,and I am extremely grateful — both as a project contributor andpersonally — for all the work that has been done and all the greatfeedback we’ve gotten.
Thank you, thank you, and thank you again. It is because of developmentlike this that OpenLayers is going to continue to move onward and upwardinto becoming the best mapping API out there.
This week is going to be an OpenLayers HackFest here in the MetaCarta office in Cambridge. In addition to the normal developers here in the office — Schuyler and myself — we’ve got our errant hacker Erik Ezureau up from south of the border, and Tim Schaub, in town from the far west. (Of course, when you live on the East Coast, anything west of New York is supposed to be Far West).
The big goal as part of this development time is to integrate the work that has been done by a number of contributors to the Vector branch of OpenLayers. This development has been geared around creating in-browser vector-based display and editing, including display of WFS lines, polygons, points, etc. This is one of the main features which is holding OpenLayers behind other mapping APIs: adding this functionality using client-side rendering will definitely increase the number of applications which can be built on top of OpenLayers.
I’m looking forward to meeting Tim, who has been one of our most prolific contributors over the open development lifetime of the OpenLayers project. With contributions both technically and socially, Tim is one of the most important contributors to the project today, and having him together with the other three developers that we have sprints with in Cambridge can only amplify the quality and quantity of code coming out of this sprint.
Many thanks to MetaCarta for making this happen, and also to the developers of the vector branch, who have put so much hard work into making the idea of client-side feature rendering a possibility. Without the hard work of people like Cameron Shorter, Bertil Chapuis and Pierre Giraud and other developers from Camp To Camp, and the numerous contributors of both testing and commenting on the code and process, there is a lot of really solid work that doesn’t look like it will be particularly difficult to merge back into trunk. They’ve done an excellent job in making it this far, and this week we hope to carry the baton home, by bringing the code back to trunk with documentation, tests, and support.
I’m hoping to keep up blogging as we go through this sprint to keep the outside world appraised of what’s going on: I aim for as much transparency as possible. Hopefully we’ll be diligent enough to keep those of you who are interested informed.
– Christopher Schmidt, MetaCarta Labs OpenLayers Hacker