Apologies for the slow response, some comments inline.


>  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.
>
>
What are Presentation and Directory services? Like what do they do?
Geocoding, reverse geocoding and routing sound great to have in GeoServer.


>
>  Both very big topics in themselves, with lots of potential for
>>
>
> Why didn't I ask before signing the contract? ;)
>
>
:) I do think you can make a great start, especially with the technologies
you've chosen. So I imagine your customer will be happy.


>
>  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.
>
>
Great.


>
>  Also, are you looking at OpenTripPlanner at all?
>>
>
> That's one of the plugin required for Routing, along with pgRouting.
>
>
Excellent.


>
>
>  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.
>
>
Awesome. Like I said above, I think those are great choices. I know TriMet
in Portland, OR has had some good success using SOLR for GeoCoding, but
theirs was too specific to their data for it to be that useful to open
source, from my understanding. So having a more generic solr geocoder would
be great.

Will the geocoder or the routing service be configurable with the same
datastores that people configure in GeoServer, like through the GUI? Or do
they take special configuration. I know OTP requires more stuff to be
configured, but it'd be great if people could start with their already
configured datastores, and then add the 'more' from there.


> Incidentally, we are also asked to develop ExtJS components to interact
> with an OpenLS server, but that's another story...
>
>
Cool. Would be great to get those as components in GeoExt, and I think
they'd be appropriate there, as it is an open standards interface. We also
work on a framework on top of GeoExt, see
http://gxp.opengeo.org/master/examples/ We tend to do geoserver specific
stuff there. It does offer a nicer plugin framework to more easily build
applications. So feel free to leverage that. You may also be able to borrow
some code from TriMet or OTP, as they have some nice GUI's for routing.


> 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 ;)
>
>
Interesting. I'll pass, just good to know what it's generally about.

>
>  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?
>
>
I'm pretty sure it could be an OWS service in GeoServer terms. WCS and WFS
both do xml over http/post, though they do offer http/get for most of the
methods (though not all, I think you can't do a WFS insert transaction
without post). And I think WPS may be just post. So I believe you should be
able to tap in to the general OWS dispatcher, which probably will help to
be more in line with the geoserver way, easier integration with like
security (though a core dev may correct me there).


> 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...
>
>
First place to read up is probably here:
http://docs.geoserver.org/latest/en/user/security/ Though that's mostly
from a user perspective, not a developer adding auth. The sub-system we use
for security is http://static.springsource.org/spring-security/site/ So
learning about that in general will help quite a bit. So yeah, I'd say dive
in to those a bit, and then ask specific questions on the developers list,
as most of the people who have worked on it are active.


> Many thanks for your patience and support!
>
>
Thanks for engaging publicly and for your coming contributions. Looking
forward to it.

best regards,

Chris


>  Chris
>>
>
> Bye, UP
>
>
>
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to