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

Wed May 27 07:19:40 PDT 2015

It's also worth mentioning that, as an interim measure, it is possible to
upgrade the Apache and PHP portions of your existing MS4W install (as
usually those are the portions people are most concerned about for
security).

This was mentioned on the Mapserver list over a year ago, and it does work,
you just have to carefully match the versions.

On Tue, May 26, 2015 at 10:25 PM, Jim Klassen <klassen.js at gmail.com> wrote:

> 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
>
>
> _______________________________________________
> Geomoose-users mailing list
> Geomoose-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geomoose-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-users/attachments/20150527/2c052f7d/attachment.html>