[Geomoose-users] A look to the future of GeoMoose?

Tue May 26 22:25:49 PDT 2015

The MapServer dependency in GeoMoose is entirely in the PHP services. 
I've been running GeoMoose since before it was GeoMoose with no PHP
services (but I have different requirements than the parcel demo app
too).  The HTML/JS portion of GeoMoose works quite well with WMS/WFS
servers and alternate services written in a variety of languages/frameworks.

IMHO, much of what is currently implemented in PHP in the demo can now
be better implemented in the browser with vector layers or using WMS
query methods.  (The downside of this is the demo services provide a
hopefully simple place for people to start from to integrate GeoMoose
with their own applications/data sources.

Identify is basically WMS GetFeatureInfo with a loop over each active layer.

Bird's Eye View and Google Street View just open a new window with a few
parameters set from the map.  I don't know why this was ever PHP.  I
have code in an extension that does this in the browser for opening up
Bing or Google maps zoomed to the user's approximate extent in
GeoMoose.  There is no reason these two couldn't be done the same way.

Select Features might be a bit tricky on the client only, but I think it
can be done with WMS and it certainly can be done with vector layers. 
Even the buffering can be done client side with JSTS as is
experimentally being done at St. Paul.

Search Parcels should be doable with WMS queries and with vector layers.

Geocoder could easily be done in the browser, although it may need a
proxy on the "local" server if CORS isn't setup.  This could probably be
done with just the Apache HTTPd configuration as long as some thought is
given to security implications.

The tricky ones as I see it are the services that generate PDFs, and my
experiments a year or so ago demonstrated that modern browsers are
honoring sizes specified in real units (inches, mm) in @media print
rules, thus allowing printing to scale direct from the browser.  (Higher
than screen DPI printing works by putting an image with the right number
of pixels into the right sized spot on the page).

As for MS4W:  If your organization finds it useful, I'd suggest talking
to Jeff and maybe throwing some funds his way to help keep new versions
coming.  Building the binaries on Windows is a lot of work.  Unlike the
Linux/Unix builds where most of the pieces such as Apache, PHP, GDAL,
etc. are already packaged, on Windows you get to start with just a C++
compiler (and not even a fully useful C library, in the POSIX sense). 
Even if someone else has built some of the dependencies you need, they
are difficult to use because of the need to match compiler versions and
build options (I count 10 separate builds on gisinternals.com for one
version of MapServer) with everything that links together.  Basically
that means you get to build the whole environment from scratch while
dealing with Windows specific build issues that turn up.

The last I checked, OSGeo4W also had issues with being out of date for
running GeoMoose. In particular, PHP being at 5.2.5 and php_mapscript at
5.6.6 (although mapserver and mapscript_python are reasonably recent at
6.4.1)

The gisinternals builds might be workable (if we drop PHP), but look
like they have a lot more work for the user to install than MS4W does.

On 05/26/2015 05:50 PM, Brent Fraser wrote:
> Dependencies are a blessing and a curse.  The great thing about MS4W
> is it supplies PHP Mapscript (along with a nice Windows installer for
> Apache, Mapserver, Proj4, and GDAL), which GeoMOOSE uses for the
> server-side  scripting of various services.  The other distributions
> don't  [usually?] supply PHP Mapscript, but they do supply the more
> popular (and better maintained?) Python Mapscript.
>
>   Maybe it's time to put the PHP scripts through the ol'
> PHP2Python-izer...
>
> Best Regards,
> Brent Fraser
>
> On 5/26/2015 3:05 PM, Eli Adam wrote:
>> Hi Bob,
>>
>> On Tue, May 26, 2015 at 12:41 PM, Bistrais, Bob
>> <Bob.Bistrais at maine.gov> wrote:
>>> First, a sincere thanks to everyone involved in the development and
>>> support
>>> of GeoMoose, it’s a great product.
>>>
>>>
>>>
>>> With regard to the future, I know that GeoMoose continues to evolve
>>> and I’m
>>> happy to see that.  My concern is with the MS4W backend, which
>>> apparently is
>>> not being further developed for Windows.  We are concerned about
>>> that at my
>> MS4W != MapServer.  See also other Windows MapServer distirbutions:
>>
>> OSGeo4W: http://download.osgeo.org/osgeo4w/x86_64/versions.html
>> Nightly builds (including of stable): http://www.gisinternals.com/
>>
>>> organization, and are looking at a possible move to using GeoServer
>>> on the
>> So MS4W not releasing doesn't logically lead to GeoServer (or other
>> MapServer replacements).  You organization could also contact Jeff
>> about funding a release, I'm not sure if that is an option.
>>
>>> backend.  I know that others on this forum have successfully used
>>> GeoServer
>>> with GM.  My question is how to handle any custom queries and
>>> functions.
>>> With MS4W, we build custom functions with PHP MapScript.   What are
>>> people
>>> doing with a GeoServer backend?  What is being planned for future
>>> releases
>>> of GeoMoose to allow for this?
>> More full featured support of GeoServer and other rendering engines is
>> indeed a great idea, however, there are plenty of reasons to pursue
>> that other than one MapServer binary distribution not releasing at
>> high frequency.  That seems to be incorrectly conflating issues.
>>
>> Indeed, perhaps the project should look at which Windows package to
>> build off of.  It was very useful for years to build off of the MS4W
>> distribution which provided a base for many MapServer projects to
>> build on top of.  GeoMoose could be packaged in OSGeo4W.  It would
>> still have a convenient installer that provides a working stack.
>> GeoMoose would also get the exposure of all the OSGeo4W users.  It
>> might mean more involvement with OSGeo4W to keep GeoMoose working with
>> the rest of the stack and coordinating dependencies.
>>
>> To me this is two mostly unrelated issues:
>> 1) default (complete) Windows GeoMoose distribution
>> 2) Improve (or abstract) support for additional rendering engines
>> (GeoServer, Mapnik, QGIS Server, etc)  - this topic could leads to
>> other architecture discussions like WFS, WPS, client-side services,
>> etc.
>>
>> Best regards, Eli
>>
>>> Thanks,
>>>
>>> Bob
>>>
>
>
> _______________________________________________
> Geomoose-users mailing list
> Geomoose-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geomoose-users