Jürgen Weichand, author of the WFS 2.0 support for the Quantum GIS, recently published his master thesis (German only) on the topic of implementing and using INSPIRE DownloadServices.
While a large focus of the thesis lies on the client side (the WFS 2.0 plugin for Quantum GIS was developed in the context of the thesis), some server side solutions were also evaluated. Since UMN mapserver does not have a WFS 2.0 implementation, only GeoServer and deegree were considered OpenSource-wise, the GO Publisher WFS was chosen as closed-source example.
Looking at table 6.7 on page 67 it seems we're doing pretty well. I'm sure the upcoming 3.2 release will improve the situation even further. And it's one of the first publications explicitly mentioning us at Occam Labs as developers of deegree!
We probably could have made an even more prominent place in the thesis if we had a nicer web administration console ready (chapter 6.2.6 mentions this as the probable reason why GeoServer was chosen for an example implementation, simple features only!). At least with the deegree handbook nearing completion it will allow future thesis writers (and all others of course) to better understand how easy it is to set up a WFS serving rich features with deegree.
Edit: I did not mean to imply that GeoServer can't serve complex features (as Andrea pointed out it has been able to do that for years), it's just not as easy to do using the web interface (which Jürgen Weichand also pointed out in this thesis).
Tuesday, January 29, 2013
Tuesday, January 15, 2013
deegree goes GitHub
There's breaking news in the deegree world, as deegree (at least deegree as in the deegree webservices) is now at GitHub! Have a look at the official repository yourself. And help yourself to a fork...
Our main reason for moving to GitHub (besides moving to git as a tool) was to make it easier for people to contribute. And that's exactly what happened! We hadn't even figured out how to properly work with pull requests and the famous git cheap branches and there was our first pull request from an external contributor!
I also extracted the deegree maven plugin into a separate repository. Have a look at the documentation I added in its wiki.
We decided to (gradually) move all developer related documentation to the wiki of the deegree webservices code base, so that should be the primary source of information for now. Links to the old wiki were added where appropriate.
So I hope to see more of those pull requests coming!
In a related note, on Friday (the 18th of January) I'll move some more deegree related projects like the old deegree 2 code base to GitHub as well, and then the svn repository will be shut down/made read only. In case some old project picks up again, I offer to migrate any of the old projects to GitHub, but for building the unchanged code base, the read-only svn should be good enough.
Friday, June 15, 2012
Bolsena 2012 #3: deegree rendering OpenStreetMap
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 ;-)
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 ;-)
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!
Friday, May 4, 2012
deegree updates
Hello everyone, it's been a while. Much has changed in deegree since.
From a project and community perspective, the new website would be the most obvious. We are also finally working on a proper documentation handbook for deegree 3, the latest work in progress can be found at http://download.occamlabs.de/deegree-webservices-handbook/.
Aside from that, our new company has started out quite nicely, we were sometimes so busy we had no time to write blog posts. I know, a lousy excuse :-)
Let's see what else has changed in deegree. The layers/themes refactoring/rewriting has taken place, and is now in a usable state. In fact, it's now the preferred way of configuring your service content.
Speaking of services, there's also a new member of deegree's little service family, the WMTS. Which means we also have a couple of tile stores to provide data.
I plan to pick out a few of the new features and post about them, but of course you're free to play around with it yourself.
Last but not least, we will of course be attending the OSGeo Bolsena Code Sprint 2012 this year. We haven't finalized our plans yet, but I'll be sure to post updates on our activities here, so stay tuned!
From a project and community perspective, the new website would be the most obvious. We are also finally working on a proper documentation handbook for deegree 3, the latest work in progress can be found at http://download.occamlabs.de/deegree-webservices-handbook/.
Aside from that, our new company has started out quite nicely, we were sometimes so busy we had no time to write blog posts. I know, a lousy excuse :-)
Let's see what else has changed in deegree. The layers/themes refactoring/rewriting has taken place, and is now in a usable state. In fact, it's now the preferred way of configuring your service content.
Speaking of services, there's also a new member of deegree's little service family, the WMTS. Which means we also have a couple of tile stores to provide data.
I plan to pick out a few of the new features and post about them, but of course you're free to play around with it yourself.
Last but not least, we will of course be attending the OSGeo Bolsena Code Sprint 2012 this year. We haven't finalized our plans yet, but I'll be sure to post updates on our activities here, so stay tuned!
Tuesday, September 27, 2011
Xerces ClassCastExceptions in multiple deployments
Today I'd like to talk about strange XML ClassCastExceptions one sometimes gets when deploying the same web application twice in the same Tomcat.
The problem occurs when you deploy for example a newer xerces library in your webapp's WEB-INF/lib directory. The problem has to do with the mechanism the XML factories are instantiated dynamically. I've always thought (and wondered) why this is so, because obviously the xerces classes have been loaded properly by the webapp classloader specific for the webapp.
After not having to deal with the problem in deegree 2 (the xerces was not specifically needed there, and the problem could be solved to remove it from WEB-INF/lib) I ran into the problem again with deegree 3, where xerces is a central and necessary library to parse XML Schemas.
I've found that there is a debug setting for the JVM -Djaxp.debug=true, which was essential for finding the problem. It showed that the ClassCastException did not actually occur when instantiating the DocumentBuilderFactory for the second time, but when XSLT was used. So what happened?
The built-in XSLT-solution in Java is xerces' counterpart, xalan. Like the built-in xerces this is an older version, apparently preconfigured to use the built-in xerces. I think what probably happens is that the used class is somewhere cached within the parent class loader (one of the global class loaders of Tomcat), but loaded with the webapp class loader of the first deployed webapp. Once the second webapp tries to use XSLT, it fails, because a different (and inaccessible) class loader was used to instantiate the parser in question. But that's pure speculation...
... which led to a hunch on my side. I thought that if each webapp had its own xalan as well, it might solve the problem, because the dynamic loading mechanism for XML factories prefers factories that can be loaded via SPI. So I deployed a recent xalan as well (plus the xalan serializer jar) and the problem was gone.
To conclude, it seems good practice to deploy recent versions of all needed (directly or indirectly) XML factories in each webapp. An indirect need for XSLT can be created as quickly as converting a OMElement to an XMLStream, so it's a good guess you need it.
PS: Another solution would be to deploy all the XML factory libs centrally in the Tomcat, but that solution has obvious disadvantages (having to fiddle with the Tomcat, not being able to use different versions across webapps).
The problem occurs when you deploy for example a newer xerces library in your webapp's WEB-INF/lib directory. The problem has to do with the mechanism the XML factories are instantiated dynamically. I've always thought (and wondered) why this is so, because obviously the xerces classes have been loaded properly by the webapp classloader specific for the webapp.
After not having to deal with the problem in deegree 2 (the xerces was not specifically needed there, and the problem could be solved to remove it from WEB-INF/lib) I ran into the problem again with deegree 3, where xerces is a central and necessary library to parse XML Schemas.
I've found that there is a debug setting for the JVM -Djaxp.debug=true, which was essential for finding the problem. It showed that the ClassCastException did not actually occur when instantiating the DocumentBuilderFactory for the second time, but when XSLT was used. So what happened?
The built-in XSLT-solution in Java is xerces' counterpart, xalan. Like the built-in xerces this is an older version, apparently preconfigured to use the built-in xerces. I think what probably happens is that the used class is somewhere cached within the parent class loader (one of the global class loaders of Tomcat), but loaded with the webapp class loader of the first deployed webapp. Once the second webapp tries to use XSLT, it fails, because a different (and inaccessible) class loader was used to instantiate the parser in question. But that's pure speculation...
... which led to a hunch on my side. I thought that if each webapp had its own xalan as well, it might solve the problem, because the dynamic loading mechanism for XML factories prefers factories that can be loaded via SPI. So I deployed a recent xalan as well (plus the xalan serializer jar) and the problem was gone.
To conclude, it seems good practice to deploy recent versions of all needed (directly or indirectly) XML factories in each webapp. An indirect need for XSLT can be created as quickly as converting a OMElement to an XMLStream, so it's a good guess you need it.
PS: Another solution would be to deploy all the XML factory libs centrally in the Tomcat, but that solution has obvious disadvantages (having to fiddle with the Tomcat, not being able to use different versions across webapps).
Subscribe to:
Posts (Atom)