deegree has been using OpenStreetMap as a background map for a couple of years now in its layer preview. That's already quite nice, but there's so much more that can be done with the OpenStreetMap data. To make a start I've begun to set up a workspace that makes use of OpenStreetMap data imported by using imposm.
To set up the data, I just followed the imposm tutorial. The workspace is configured using the production table schema, so make sure you run imposm --deploy-production-tables once you're done importing the data.
The workspace is located in the deegree svn (deegree-workspace-osm), so if you want to have a look, go ahead. It uses the GeoServer styles that were used in the FOSS4G benchmarking 2011. It still needs a little tweaking to improve the map quality (labels and stuff), but the styles worked out of the box. The labels along roads/waterways seem to be repeating without taking the gap configuration into account, so analysing the deegree renderer here seems to be in order.
Apart from that, this enables you to create your own maps based on the OpenStreetMap data. The new workspace is the place to start, you can just adapt the styles for your own needs or create your own layers any way you want.
We at Occam Labs plan to provide an online demo using the German and Dutch OSM extracts from Geofabrik. We already did some tests on these datasets, and the result was quite promising. So stay tuned for updates on this one!
Edit: Forget the comment about the deegree renderer not taking the gap into account. It didn't, but now it does, another successful Bolsena bugfix ;-)
I will be posting mainly about various geospatial topics concerning the deegree project. Other topics will include technical details about dealing with Java, maven and so forth, and possibly other geek stuff I feel may be interesting to others.
Friday, June 15, 2012
Wednesday, June 13, 2012
Bolsena 2012 #2: Lenient SLD/SE evaluation in deegree
In preparation of setting up a new demo workspace (more on this later), I've been working on making the SLD/SE filter and expression evaluation more lenient. Until now, the parser already ignored invalid SLD/SE bindings within style files, but the evaluator of expressions (like PropertyNames) and filters was strict.
The new evaluation will try to fix missing namespace bindings for PropertyNames in expressions and filters. Such broken bindings can be hard to find, because even though the schemas require you to use qualified names/xpaths, normal schema validators will not find these errors.
One nice (and intended) side effect is that SLD files used to configure GeoServer can now be used without modification (unless some special GeoServer constructs are used).
Since it is still desirable to write valid documents, you can set a class to DEBUG in your log4j.configuration to see what PropertyNames are being repaired:
The new evaluation will try to fix missing namespace bindings for PropertyNames in expressions and filters. Such broken bindings can be hard to find, because even though the schemas require you to use qualified names/xpaths, normal schema validators will not find these errors.
One nice (and intended) side effect is that SLD files used to configure GeoServer can now be used without modification (unless some special GeoServer constructs are used).
Since it is still desirable to write valid documents, you can set a class to DEBUG in your log4j.configuration to see what PropertyNames are being repaired:
log4j.logger.org.deegree.filter.Filters = DEBUG
Monday, June 11, 2012
Bolsena 2012 #1: deegree on the couch 2
Following up on the 2011 Bolsena event, we got news from Volker Mische that we could try to adapt the GeoCouch feature store created then to the new 2.0 version of Couchbase.
This would allow for easy, transparent use of multiple Couchbase machines as a backend, and might also improve the speed situation of our last experiments.
Turns out it was only half a day of work to adapt the existing approach to the Couchbase one. With a little URL/URI fiddling the indexes could be used same as before, with only minor changes. We now used the approach to store the GML blob directly in the JSON document (base64 encoded).
Actually, using the Java libraries for Couchbase was pretty straightforward, and resulted in much cleaner (and much less) code than before for inserting. Since the Java libs use a custom protocol, inserting also seemed quite a bit faster.
We left the query interface to still use the old HTTP interface (with only minor URL/URI fiddling), and querying is around 50% slower than our PostGIS blob storage. We expect that using a few performance tweaks would result in approximately the same speed (we're not using any compression now, and using the Couchbase Java libs would probably also be an improvement).
So all said, the first day was already quite a success. Although the weather started out with rain and comparatively low temperature, the sun came out around the same time we did our performance tests. Must be an omen ;-)
In case you're wondering, Markus is currently working on the documentation. We're going to try to expose some test subjects here to the handbook... Actually, it seems that quite a lot of the people here have already used or are using deegree, so maybe we can actually find someone willing :-)
Stay tuned for more Bolsena news!
This would allow for easy, transparent use of multiple Couchbase machines as a backend, and might also improve the speed situation of our last experiments.
Turns out it was only half a day of work to adapt the existing approach to the Couchbase one. With a little URL/URI fiddling the indexes could be used same as before, with only minor changes. We now used the approach to store the GML blob directly in the JSON document (base64 encoded).
Actually, using the Java libraries for Couchbase was pretty straightforward, and resulted in much cleaner (and much less) code than before for inserting. Since the Java libs use a custom protocol, inserting also seemed quite a bit faster.
We left the query interface to still use the old HTTP interface (with only minor URL/URI fiddling), and querying is around 50% slower than our PostGIS blob storage. We expect that using a few performance tweaks would result in approximately the same speed (we're not using any compression now, and using the Couchbase Java libs would probably also be an improvement).
So all said, the first day was already quite a success. Although the weather started out with rain and comparatively low temperature, the sun came out around the same time we did our performance tests. Must be an omen ;-)
In case you're wondering, Markus is currently working on the documentation. We're going to try to expose some test subjects here to the handbook... Actually, it seems that quite a lot of the people here have already used or are using deegree, so maybe we can actually find someone willing :-)
Stay tuned for more Bolsena news!
Subscribe to:
Posts (Atom)