[Geomoose-users] Installing Geomoose; What next?

Jonathan Moules jonathanmoules at warwickshire.gov.uk
Wed Aug 1 09:58:11 PDT 2012


> The ms4w stuff is expecting to be installed at the drive root (e.g. c:\ms4w)
> and that part is in the directions.  I didn't even know there was a way to
> move it.

Ah, that would certainly explain a few things then. Now I re-check the
documentation I went through it is kind of implied that stuff should
be in the root.


> GeoMoose doesn't have anything to log per say.  PHP should log with the web
> server, but apparently decided to mess up its output instead.  I wonder if
> this is because IIS doesn't honor the difference between stdout and stderr.
> The bulk of GeoMoose is HTML/JS and runs in the client's browser.  This part
> logs to console.log() and can be seen with something like Firebug.

The IIS logs only contain 200, 304 response codes (along with a few
404's for the favico)
After some searching, it seems the general consensus is that PHP
doesn't log to IIS automatically. Instead the php.ini file should be
altered per http://php.net/manual/en/install.windows.manual.php - the
error_log shoud be set (in your distribution its unset).

> In this case it can't.  It is parsing as XML and this failed so the XHR call
> returns an error.  More importantly, the generic error is more friendly for
> users.  It is assumed that site admins will know to check what is really
> happening in something like Firebug.  I thought we had a page on what to do
> if GeoMoose didn't work that covered this stuff, but maybe that was in the
> GeoMoose workshop (e.g. at FOSS4G 2011) and didn't make it to official docs.

I certainly do appreciate that error from a user perspective (its not
as scary as our current web-gis), however:
(a) What happens if the user gets it but the admin can't replicate it?
By giving the user a proper error description (and/or proper logging),
they are then able to provide useful information to the admin.
(b) Firebug is all well and good but you can't assume the admins know
about it when in the FAQ (
http://www.geomoose.org/docs/faq.html#geomoose-is-supposed-to-be-easy-to-set-up-but-it-seems-difficult-why
) the project is assuming the admins are actually GIS'ers rather than
web-types.
(c) The only reference to firebug I can find is -
http://www.geomoose.org/trunk/docs/faq.html#why-am-i-getting-these-pink-tiles-when-i-look-at-geomoose
- which just gives a general "go use it to fix the pink tiles"
comment. No specifics.


> Please feel free to contribute.  IIS7 installations have been done before,
> but they aren't the common route and most of the developers don't have
> access to IIS7 to test or document against.

My contributions are typically best made in the realm of QA (already
reported about 10 issues to the tracker). Plus, as you can probably
tell, I'm not really in a position to document stuff given my own
install is rather borked. :-)
However, all the information I used is out there already (combined
with stuff from this thread), though not all of it is error-free or
entirely clear whats going on:
Install Mapserver:
http://mas-kono-tes.blogspot.co.uk/2011/03/getting-mapserver-to-work-on-iis75.html
Install GeoMoose:
http://osgeo-org.1560.n6.nabble.com/Geomoose-users-Install-GeoMOOSE-using-IIS-7-td4941963.html

Thanks again for the pointers though.
Jonathan





On 1 August 2012 14:45, Jim Klassen <klassen.js at gmail.com> wrote:
> The ms4w stuff is expecting to be installed at the drive root (e.g. c:\ms4w)
> and that part is in the directions.  I didn't even know there was a way to
> move it.
>
> So lessons here:
> (a) It would be nice if GeoMoose had some sort of logs of its own. I can't
> seem to find any indication of any existing in any of the directories.
>
> GeoMoose doesn't have anything to log per say.  PHP should log with the web
> server, but apparently decided to mess up its output instead.  I wonder if
> this is because IIS doesn't honor the difference between stdout and stderr.
> The bulk of GeoMoose is HTML/JS and runs in the client's browser.  This part
> logs to console.log() and can be seen with something like Firebug.
>
> (b) GeoMoose should probably output PHP errors directly rather than hide
> them behind a generic message. This would make troubleshooting a lot easier.
>
> In this case it can't.  It is parsing as XML and this failed so the XHR call
> returns an error.  More importantly, the generic error is more friendly for
> users.  It is assumed that site admins will know to check what is really
> happening in something like Firebug.  I thought we had a page on what to do
> if GeoMoose didn't work that covered this stuff, but maybe that was in the
> GeoMoose workshop (e.g. at FOSS4G 2011) and didn't make it to official docs.
>
>
> (c) Documentation for IIS7 installation would be extremely helpful.
>
> Please feel free to contribute.  IIS7 installations have been done before,
> but they aren't the common route and most of the developers don't have
> access to IIS7 to test or document against.
>
> On Aug 1, 2012, at 4:45 AM, Jonathan Moules wrote:
>
>
> Well, the IIS logs have nothing in them - they're just showing 200's (so the
> page is fine from that perspective). My Logs question was more relating to
> GeoMoose itself keeping logs.
>
> If I navigate to the getmapbook.php page itself: (
> http://localhost/GeoMoose/php/getmapbook.php ) - this seems to be returning
> an error:
>
> XML parsing failed
> XML parsing failed: syntax error (Line: 470, Character: 10)
> Reparse document as HTML
> Error:
> unexpected text (non-whitespace text outside root element)
> Specification:
> http://www.w3.org/TR/REC-xml/
> 467:
> 468:   <tool name="my_tool" title="My service" type="service"
> selectable="false" service="newservice" show-label="true"
> icon-class="my_tool_icon"/>
> 469:  </toolbar>
> 470: </mapbook>
> 471: PHP Warning:  PHP Startup: Unable to load dynamic library
> '/ms4w/Apache/php/ext/php_curl.dll' - The specified module could not be
> found.
> 472:  in Unknown on line 0
> 473: PHP Warning:  PHP Startup: Unable to load dynamic library
> '/ms4w/Apache/php/ext/php_gd2.dll' - The specified module could not be
> found.
> 474:  in Unknown on line 0
> 475: PHP Warning:  PHP Startup: Unable to load dynamic library
> '/ms4w/Apache/php/ext/php_mapscript.dll' - The specified module could not be
> found.
> 476:  in Unknown on line 0
> 477: PHP Warning:  PHP Startup: Unable to load dynamic library
> '/ms4w/Apache/php/ext/php_ogr.dll' - The specified module could not be
> found.
> 478:  in Unknown on line 0
>
> I've confirmed those files do exist, they're in
> C:\inetpub\wwwroot\ms4w\Apache\php\ext\
> Geomoose is in: C:\inetpub\wwwroot\ms4w\apps\geomoose2\
>
> All the ms4w stuff is in: C:\inetpub\wwwroot\ms4w\
> Except MapServer and a couple of directories which I've moved (per the
> instructions) to: c:\mapserver\
>
> I think I've followed the instructions (they're disparate and scattered
> across numerous pages, so its a bit hard to be sure), so maybe I missed this
> bit, or it wasn't in them.
>
> Looking in php.ini, it states:
> extension_dir = "/ms4w/Apache/php/ext/"
>
> So I manually changed it to:
> extension_dir = "/inetpub/wwwroot/ms4w/Apache/php/ext/"
> It can now load the extensions (php.ini was in the C:\mapserver, per the
> instructions, whereas the extensions weren't).
>
> The result is that GeoMoose now works.
>
>
> So lessons here:
> (a) It would be nice if GeoMoose had some sort of logs of its own. I can't
> seem to find any indication of any existing in any of the directories.
> (b) GeoMoose should probably output PHP errors directly rather than hide
> them behind a generic message. This would make troubleshooting a lot easier.
> (c) Documentation for IIS7 installation would be extremely helpful.
>
> Thanks for the help folks, I'm sure I'll have more questions soon.
> Jonathan
>
> On 31 July 2012 15:09, Jim Klassen <klassen.js at gmail.com> wrote:
>>
>> I have no experience with GeoMoose on IIS but...
>>
>> You said you were getting an error saying GeoMoose could not load the
>> mapbook.  This means either the server returned an error (404,500, etc) or
>> otherwise didn't return a valid mapbook when GeoMoose requested
>> ./php/getmapbook.php.
>>
>> It would really help if you had something akin to Firebug so you could see
>> what the server is sending on the getmapbook.php call.  My guess is if you
>> haven't moved anything from the base ms4w install is that you don't have PHP
>> configured properly and IIS is sending the PHP file rather than executing
>> the PHP file and sending the results.
>>
>> There are logs/error messages, but I have no idea where for IIS.  With
>> apache look for error.log and access.log to see what the server is up to.
>> And as I said above, something like Firebug (console and network tabs are
>> most useful) lets you see what GeoMoose is up to.
>>
>> Also, the local settings you are looking at would not change if the
>> mapbook would get successfully loaded or not.  mapserver_url could effect if
>> any local maps show up or not after the mapbook in loaded.
>>
>> On Jul 31, 2012, at 5:12 AM, Jonathan Moules wrote:
>>
>> HI List,
>> I'm still not making any headway. I've now read/glanced over all of the
>> documentation here: http://www.geomoose.org/docs/index.html - but am none
>> the wiser.
>> Everything is still set to the defaults, though I have started playing
>> with the "paths" in local_settings.ini.
>>
>> Unfortunately the documentation doesn't make it clear where these relative
>> paths are relative to, so I can't be sure if they're correct or not.
>>
>> My paths:
>> [paths]
>> root=/ms4w/apps/geomoose2/maps/
>> mapserver_url=/GeoMoose_cgi/mapserv.exe
>> temp=/ms4w/tmp/ms_tmp/
>>
>> Documentation:
>> root – root for the map (only configured through local_settings.ini)
>> temp – web accessible location of the temp files relative to the root of
>> the domain (only configured through local_settings.ini)
>>
>> While the "temp" one specifies "root of the domain", is that the web
>> domain (i.e., "localhost"), in which case shouldn't it be called "temp_url"
>> like the "mapserver_url" variable is? I have a virtual directory for ms_tmp
>> set up, but changing this to point at that doesn't work either.
>>
>> Any thoughts? How do I debug what the actual problem is? Are there error
>> logs somewhere?
>> Thanks,
>> Jonathan
>>
>>
>> On 30 July 2012 13:12, Jonathan Moules
>> <jonathanmoules at warwickshire.gov.uk> wrote:
>>>
>>> Hi,
>>> I've managed to (eventually) get GeoMoose 2.6 & MapServer-4-Windows
>>> working with IIS7. But now when I try and access GeoMoose I get the
>>> following:
>>>
>>>
>>> "Could not load a mapbook. If you are the system administrator, you
>>> should look into this, if you are not the system administrator you should
>>> tell them about this. Suggestions:
>>> The mapbook may not be returning XML.
>>> The mapbook may be returning malformed XML.
>>> PHP may not be responding."
>>>
>>> PHP is running (a simple php script calling phpinfo(); in the GeoMoose
>>> directory shows that).
>>>
>>> Unfortunately at this point the documentation seems to have a gap. I can
>>> find massive amounts of detailed information about what to put in my
>>> mapbooks, what different config settings etc do, but there seems to be a
>>> lack of over-arching documentation. It doesn't tell me clearly where the
>>> mapbooks are, what settings I need to tweak to point them at the mapbooks,
>>> where the config settings.ini file is. Parts of this information seem to be
>>> scattered around (I eventually managed to find
>>> http://geomoose.org/docs/settings.html  (I'd suggest this be pointed to from
>>> "Next steps" here - http://www.geomoose.org/docs/install_ms4w.html )).
>>>
>>> Shouldn't the it be loading the demo mapbook? What do I need to change
>>> next? settings.ini is pointing to "mapbook.xml" and there is one of them in
>>> the conf directory too.
>>>
>>> Anyone have any thoughts?
>>> Thanks,
>>> Jonathan
>>
>>
>>
>>
>> This transmission is intended for the named addressee(s) only and may
>> contain sensitive or protectively marked material up to RESTRICTED and
>> should be handled accordingly. Unless you are the named addressee (or
>> authorised to receive it for the addressee) you may not copy or use it, or
>> disclose it to anyone else. If you have received this transmission in error
>> please notify the sender immediately. All email traffic sent to or from us,
>> including without limitation all GCSX traffic, may be subject to recording
>> and/or monitoring in accordance with relevant legislation.
>> _______________________________________________
>> Geomoose-users mailing list
>> Geomoose-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/geomoose-users
>>
>>
>
>
>
> This transmission is intended for the named addressee(s) only and may
> contain sensitive or protectively marked material up to RESTRICTED and
> should be handled accordingly. Unless you are the named addressee (or
> authorised to receive it for the addressee) you may not copy or use it, or
> disclose it to anyone else. If you have received this transmission in error
> please notify the sender immediately. All email traffic sent to or from us,
> including without limitation all GCSX traffic, may be subject to recording
> and/or monitoring in accordance with relevant legislation.
>
>


This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us,  including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.


More information about the Geomoose-users mailing list