<div dir="ltr">Hello,<div style>I took the suggestion of James and I'm developing my own flavor of API in Delphi + TatukGIS. </div><div style>My 2 cents about the "Service abstraction" matter: I strongly believe that the ability to write server side extensions and API in whatever language could be a definitive plus for GeoMoose. </div>
<div style>For this to work better, I suggest to use more standard protocols for the API. For instance, the API and the javascript side should exchange feature data using GML or GeoJson or other standard/widely used protocol, so that one can save valuable time using libraries - both commercial (e.g.: TatukGIS, Esri) and open source (e.g.: SharpMap) - that already are able to parse and manage this data.</div>
<div style>Using standard protocol whenever possible should also help to diffuse the use of the GeoMoose project.</div><div style><br></div><div style>Fabrizio</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Jun 12, 2013 at 11:26 PM, Eli Adam <span dir="ltr"><<a href="mailto:eadam@co.lincoln.or.us" target="_blank">eadam@co.lincoln.or.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, Jun 12, 2013 at 2:13 PM, Bistrais, Bob <<a href="mailto:Bob.Bistrais@maine.gov">Bob.Bistrais@maine.gov</a>> wrote:<br>
> Not exactly. We are still in the planning stages with regard to feature editing. All we know for sure is that we will see a demand for it. We haven't yet tried the WFS-T approach (another item on my to-do list). We don't have GeoServer implemented at this time. As you've seen from me in the past, we are not allowed to have PostGIS (per IT department policy). So those are my major restrictions.<br>
<br>
</div>Ah, right. I recently noticed that the FeatureServer website has been<br>
polished up, <a href="http://featureserver.org/" target="_blank">http://featureserver.org/</a> and that SpatialLite is now a<br>
supported WFS-T backend. This could be convenient for mobile or<br>
offline connections as well.<br>
<div class="im"><br>
><br>
> So with that in mind, I would entertain different options for feature editing which would work within my stipulations. Conceivably, we could use WFS-T with our ESRI back end, although they sometimes seem to have their own version of "open standards" and "interoperability".<br>
<br>
</div>My understanding is that sometimes the ESRI defaults don't make it<br>
easy to implement OGC standards well, but that there is a way to<br>
eventually do it (sometimes with hurdles or non-intuitive<br>
requirements). The OGC has a listing here,<br>
<a href="http://www.opengeospatial.org/resource/products/details/?pid=868" target="_blank">http://www.opengeospatial.org/resource/products/details/?pid=868</a><br>
<br>
HTH, Eli<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> -----Original Message-----<br>
> From: <a href="mailto:geomoose-users-bounces@lists.osgeo.org">geomoose-users-bounces@lists.osgeo.org</a> [mailto:<a href="mailto:geomoose-users-bounces@lists.osgeo.org">geomoose-users-bounces@lists.osgeo.org</a>] On Behalf Of Eli Adam<br>
> Sent: Wednesday, June 12, 2013 5:07 PM<br>
> To: James Klassen<br>
> Cc: <a href="mailto:geomoose-users@lists.osgeo.org">geomoose-users@lists.osgeo.org</a><br>
> Subject: Re: [Geomoose-users] Services abstraction, what's the status of this?<br>
><br>
> Bob and Bob,<br>
><br>
> Are there reasons that you don't want to do editing with WFS-T?<br>
> <a href="http://www.geomoose.org/docs/vector_layers/geoserver_setup.html" target="_blank">http://www.geomoose.org/docs/vector_layers/geoserver_setup.html</a><br>
><br>
> Eli<br>
><br>
><br>
> On Wed, Jun 12, 2013 at 1:39 PM, James Klassen <<a href="mailto:klassen.js@gmail.com">klassen.js@gmail.com</a>> wrote:<br>
>> Also, most of the items you listed are more appropriate as extensions<br>
>> than services at least in so far as they interact with GeoMoose.<br>
>><br>
>> As an aside, some things that are now services may be moved into<br>
>> JavaScript within GeoMoose if feasible. Modern browsers are much<br>
>> better than the situation was in 2006. So things like printing,<br>
>> select, identify, etc. may be doable in the browser and backed by<br>
>> WMS/WFS rather than needing direct server side help. This greatly<br>
>> simplifies the security model on the server and also helps people who<br>
>> want to do incremental updates as it uncouples GeoMoose version from<br>
>> MapServer version and allows things like multiple MapServer versions,<br>
>> a mix of MapServer and GeoServer (or others) and having layers sourced from different servers altogether (cloud like).<br>
>><br>
>> On Jun 12, 2013 3:31 PM, "James Klassen" <<a href="mailto:klassen.js@gmail.com">klassen.js@gmail.com</a>> wrote:<br>
>>><br>
>>> The short answer is users are encouraged to write their own services<br>
>>> conforming to the GeoMoose service API to do whatever tasks are<br>
>>> necessary in whatever environment best fulfills their needs.<br>
>>><br>
>>> The GeoMoose project currently maintains some services in PHP. I<br>
>>> have implemented custom services (simultaneously compatible with<br>
>>> multiple versions GeoMoose and other software) in Perl, Python, Ruby<br>
>>> (CGI and Rails), and C over the years.<br>
>>><br>
>>> There was talk at FOSS4G-NA and at the last PSC meeting about<br>
>>> reworking the services that are included as part of the demo. The<br>
>>> primary reason is to remove some artificial limitation based around accessing local mapfiles.<br>
>>> This work would likely not be done in PHP. However, this doesn't<br>
>>> mean PHP services will stop working. There is a published API for<br>
>>> how GeoMoose interacts with services and there are no plans to break<br>
>>> backwards compatibility with that API.<br>
>>><br>
>>> Note, however, future demos (essentially a configuration) may be<br>
>>> based on future default services, which may change some file layouts.<br>
>>><br>
>>> On Jun 12, 2013 2:41 PM, "Basques, Bob (CI-StPaul)"<br>
>>> <<a href="mailto:bob.basques@ci.stpaul.mn.us">bob.basques@ci.stpaul.mn.us</a>> wrote:<br>
>>>><br>
>>>> Bob,<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Both would be supported, and more, Jim has indicated PYTHON as an<br>
>>>> option as well.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> bobb<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> From: Bistrais, Bob [mailto:<a href="mailto:Bob.Bistrais@maine.gov">Bob.Bistrais@maine.gov</a>]<br>
>>>> Sent: Wednesday, June 12, 2013 2:22 PM<br>
>>>> To: Basques, Bob (CI-StPaul); <a href="mailto:geomoose-users@lists.osgeo.org">geomoose-users@lists.osgeo.org</a><br>
>>>> Subject: RE: Services abstraction, what's the status of this?<br>
>>>><br>
>>>><br>
>>>><br>
>>>> I'm a PHP user. Since we have a number of applications built on<br>
>>>> GeoMoose/PHP, I'm concerned- would I need to convert everything to<br>
>>>> Perl in future upgrades, or do you mean that PHP AND Perl would be<br>
>>>> supported for services?<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Certainly interested in the feature editing piece. AVL is neat but<br>
>>>> I think my anticipated needs would require feature editing more.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> From: <a href="mailto:geomoose-users-bounces@lists.osgeo.org">geomoose-users-bounces@lists.osgeo.org</a><br>
>>>> [mailto:<a href="mailto:geomoose-users-bounces@lists.osgeo.org">geomoose-users-bounces@lists.osgeo.org</a>] On Behalf Of<br>
>>>> Basques, Bob<br>
>>>> (CI-StPaul)<br>
>>>> Sent: Wednesday, June 12, 2013 3:00 PM<br>
>>>> To: <a href="mailto:geomoose-users@lists.osgeo.org">geomoose-users@lists.osgeo.org</a><br>
>>>> Subject: [Geomoose-users] Services abstraction, what's the status of<br>
>>>> this?<br>
>>>><br>
>>>><br>
>>>><br>
>>>> All,<br>
>>>><br>
>>>><br>
>>>><br>
>>>> So, I'm setting up a new install of GeoMoose (among other things,<br>
>>>> read<br>
>>>> on) and wondering about where the services abstraction ideas are<br>
>>>> currently at? While I know PHP is popular, I much prefer PERL for<br>
>>>> the services side of things.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> I would like to use PERL in place of PHP for example. I just want<br>
>>>> the option of using another language. I know this has been talked<br>
>>>> about in the recent past and I guess I'm looking harder at it now.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> So,<br>
>>>><br>
>>>> * Where in the release cycle is this capability at?<br>
>>>><br>
>>>> * Should I (we) progress this internally first and then just<br>
>>>> pass back to GeoMoose as a pass fail sort of endeavor for inclusion<br>
>>>> in GeoMoose, or . . .<br>
>>>><br>
>>>> * Put out a spec and ask for bids here?, or . . . ???<br>
>>>><br>
>>>><br>
>>>><br>
>>>> I also have some more stuff coming down the line, but figured I<br>
>>>> would start with the above first to get a conversation going here.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> --------------<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Future stuff:<br>
>>>><br>
>>>> * Feature updating (PUSH) from a service. (IE. GPS point<br>
>>>> Tracking, and Weather overlays)<br>
>>>><br>
>>>> * Alternate map Views (spawning service from GeoMoose) for<br>
>>>> OpenLayers and 3D(HTML5) constructs, and other reporting packages . . .<br>
>>>><br>
>>>> * Old timey (City of Saint Paul) Popup capabilities (some of the<br>
>>>> GeoMoose developers know what I'm talking about here) or something<br>
>>>> very close.<br>
>>>><br>
>>>> * Addition of a optional service side (server component)<br>
>>>> construct for handling of feature editing in GeoMoose. I know this<br>
>>>> is a whole new side of things, and it can become it's own thing if<br>
>>>> need be, project wise. I haven't started this here yet, but it's<br>
>>>> next after AVL has settled down. See next item<br>
>>>><br>
>>>> * Addition of a AVL (location tracking) service (server<br>
>>>> component). I actually have this well on it's way already and am<br>
>>>> wondering about how to integrate it with GeoMoose as well as put the<br>
>>>> project out as OpenSource, and with GeoMoose or on it's own as a<br>
>>>> companion piece. Does it make and sense to put it under the<br>
>>>> GeoMoose project umbrella, or should it be it's own thing? My vote is to add it to GeoMoose in some form.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Thanks<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> Geomoose-users mailing list<br>
>>>> <a href="mailto:Geomoose-users@lists.osgeo.org">Geomoose-users@lists.osgeo.org</a><br>
>>>> <a href="http://lists.osgeo.org/mailman/listinfo/geomoose-users" target="_blank">http://lists.osgeo.org/mailman/listinfo/geomoose-users</a><br>
>>>><br>
>><br>
>> _______________________________________________<br>
>> Geomoose-users mailing list<br>
>> <a href="mailto:Geomoose-users@lists.osgeo.org">Geomoose-users@lists.osgeo.org</a><br>
>> <a href="http://lists.osgeo.org/mailman/listinfo/geomoose-users" target="_blank">http://lists.osgeo.org/mailman/listinfo/geomoose-users</a><br>
>><br>
> _______________________________________________<br>
> Geomoose-users mailing list<br>
> <a href="mailto:Geomoose-users@lists.osgeo.org">Geomoose-users@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/geomoose-users" target="_blank">http://lists.osgeo.org/mailman/listinfo/geomoose-users</a><br>
><br>
_______________________________________________<br>
Geomoose-users mailing list<br>
<a href="mailto:Geomoose-users@lists.osgeo.org">Geomoose-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/geomoose-users" target="_blank">http://lists.osgeo.org/mailman/listinfo/geomoose-users</a><br>
</div></div></blockquote></div><br></div>