On 17/01/2013 17:50, Chris Holmes wrote:
OpenLS would be a cool improvement to have as modules on GeoServer. Are
Glad to hear that.
you doing all of the OpenLS services? Or just a subset? I feel like
there's five or six, though I'm not sure if they're all useful. I think
the most interesting ones to a wider audience are geocoding and routing.
Yes, they defined Reverse Geocoding, Presentation & Directory services, too.
We are going to develop Geocoding, Reverse Geocoding and Routing. ATM we are discussing with our client about Presentation usefulness, as we have some doubt about that.
Both very big topics in themselves, with lots of potential for
Why didn't I ask before signing the contract? 
innovation. My one naive advice is to be sure to keep your specification
implementation nice and orthogonal to the backend, so that other
developers can experiment with different implementations but all be able
to easily meet the OpenLS spec requirements.
Requirements are very clear: we need to add an OpenLS interface to GeoServer and design a backend interface to make it pluggable.
Also, are you looking at OpenTripPlanner at all?
That's one of the plugin required for Routing, along with pgRouting.
this point. I need to look in to some others that people have sent in (I
am at OpenPlans). When you do mail it if you could also email me a scan
of it that could be helpful.
Sure I will. Thanks!
Definitely do write up your design thoughts to the list. I'm not sure if
Ok, I will try.
At the moment we are going with this design: OLS module is the main module that implements the OpenLS services. It manages XML over HTTP/POST requests and dispatches them to the appropriate handler (one handler per OpenLS service).
Each handler reads its configuration from the GeoServer web console (OLS-WEB module), where you can set parameters like end point of backend web services, hostname of remote server and so on (I think you got the idea...)
A few plugin (will) exist to connect to various backends. They are:
- for Geocoding
- RFC 59 (please read about this below)
- SOLR
- for Reverse geocoding
- SOLR
- for Routing
- OTP
- pgRouting
Each one will live in its own project and be activated automagically by Spring if it finds the JAR in the classpath.
Incidentally, we are also asked to develop ExtJS components to interact with an OpenLS server, but that's another story...
Questions, opinions, hints and flames are welcome!
see what you were thinking when you built it. I'm also curious what
RFC59 is, I couldn't find any reference online to it.
I can easily understand that 
RFC59 is one of the Tuscany Region interoperability standard. Here in Tuscany the local government pays quite a lot of attention to technical definitions of standards regarding the various domains of their IT infrastructure.
They founded a board to discuss and standardize infrastructures, protocols and services, ranging from medical data interchange (based on HL7) to street networks.
So, RFC59 is Regione Toscana geocoder service. It's very small compared to OpenLS Geocoder Core Service, but it needs to be taken in account as our customer asked for that, both because he is a public one and because he wants to have the opportunity to check the Geocoding design against two backends.
I can give you the URL of the web site, but I'm afraid you'll need a quick Italian course to begin reading the docs
But yeah, stay in touch with the list, keep us updated on your plans and
progress.
The plan is a very busy one: we need to deliver in a couple of months.
I would like to ask some more question, just for the ones that have been able to read all this concise email without falling asleep suddenly at line 3
1. AFAIK, OpenLS binding is XML over HTTP/POST. Maybe there is a SOAP profile, too, but definitively no HTTP/GET method a-la WMS. So the service is not an OWS service in GeoServer terms, correct?
2. OpenLS may require authentication/authorization. Any hint on how to integrate in GeoServer one? I must admit that I didn't look at that yet...
Many thanks for your patience and support!
Chris
Bye, UP