[Geomoose-users] Question on Jump To list

[Eli Adam]

On Mon, Aug 20, 2012 at 3:04 PM, Jim Klassen <klassen.js at gmail.com> wrote:
> 1) We already have selects/drop down lists that can be automatically
> populated on a service call.

If it is simple, we might want to include it in the demo.

>
> 2)  I implemented a few versions of generic search service (that implements
> option 2) a number of years ago.  Having GeoMoose loop through all (or a
> subset) of layers was too inefficient.
>
> What I found was to reliably and quickly handle queries I needed to cache
> the indexed fields, geometry (or at least bounding box), and source layer
> (from the perspective of the catalog to turn activate the layer).  I wrote a
> crawler (implies scheduled task) that read the mapbook and connected to the
> map-sources and ended up caching this information in PostGIS.  At the time
> this "connection" was handled by adding a mode to mapserver (via mapscript)
> to use some metadata in each mapfile to indicate which layers and fields to
> index and the human friendly name of said fields.  In practice, this was
> simply a second template format (from the popups) and also disabled
> min/maxscaledenom.  The reason for this method is it allowed for non-local
> MapServers (we had more than one host that served our data).
>
> This does make the site a lot more user friendly, but it comes at a cost of
> additional components/complexity for the administrator and will be difficult
> to achieve if we are limiting ourselves to thing that can run out of the box
> using only MS4W.


I also like the idea of a blank search box for everything.  Users seem
way more inclined to type something and respond to results (i.e.
reading and clicking) than to read first (i.e. determine which dataset
they want to search and how).  This is how search engines work and
seems to be many users defacto interaction method.

In the past when full text search was still a contrib, I looked at
full text search in Postgresql across multiple tables/fields (taxlot
owners/taxlot addresses/taxlot id numbers, road names, geographic
names (GNIS)/city/stream/mountain/etc, fire districts, watersheds, and
other spatial themes) and returning partial results in categories and
the user could then click on one of the categories in the form "I am
looking for... a taxlot owner, a taxlot address, a street, a city, a
stream, a mountain, a fire district,")  Clicking on one of those would
then return more information about the possible options in that
category.  This never got beyond an OpenLayers/PHP/Postgres demo but
the query portion at least was of acceptable speed.  Like the method
Jim described, this is getting far away from the simple out of the box
MS4W installation and indeed requires a Postgresql backend and what
some might consider extensive data preparation.

OGR has a new SQLite dialect.  We could perhaps build on this to make
use of SQLite FTS extensions, but this too would add dependencies and
presumably have performance degrading with dataset size and numbers.
So it could work really well in the demo with a small number of
taxlots and cities and then work poorly when you put lots of data in
it.

I like a generic search idea but most approaches I know are complex to
configure and seem overly specific to the data.  Perhaps someone can
come up with a good approach that meets all the constraints.

Bests, Eli

>
> On Aug 20, 2012, at 3:35 PM, Mark Volz wrote:
>
> Hello,
>
> Just my two cents on the subject.
>
> 1)  I actually like the jump-to boxes.  I think they work really well when
> there are less than 35 or so jump-to locations.
>
> 2)  One idea I had that might be interesting for searching is having the
> option to include an generic search box similar to how browsers have web
> search built directly into the browser.  This way the user wouldn’t have to
> be concerned about changing the search to “search parcel” or “search
> township” etc.  Instead they would just type in what they are looking for
> and the GeoMOOSE configuration could store what layers and fields that it
> should search.  I don’t know if that would be possible or not, or if it
> would be difficult.  However I think that it might make the site more user
> friendly.
>
> Mark Volz
> GIS Specialist
>
> From: geomoose-users-bounces at lists.osgeo.org
> [mailto:geomoose-users-bounces at lists.osgeo.org] On Behalf Of Jim Klassen
> Sent: Monday, August 20, 2012 1:53 PM
> To: Bistrais, Bob
> Cc: geomoose-users at lists.osgeo.org
> Subject: Re: [Geomoose-users] Question on Jump To list
>
> This is exactly why I don't like the jump to list (and have lobbied for its
> removal since at least GeoMoose 2.0).  It works (sort of) for smaller
> installations, but even then it is a hassle of having to calculate and place
> bounding boxes in the mapbook when you probably already had them in a vector
> format somewhere.
>
> Personally, I think it is more useful and more maintainable to implement the
> jump to functionality as a search on a layer that has your polygons.  Find
> town by name (or partial name); return a list of matches; user selects the
> one they want and the map zooms/pans to the selection.  This also lets you
> have more than one category of jump-to... say counties, zip codes, park
> names, and even potentially addresses.
>
> Just my 2 cents.
>
> Jim
>
> On Aug 20, 2012, at 1:08 PM, Bistrais, Bob wrote:
>
>
> I have modified the Jump To list on my GM 2.6 applications so they contain a
> complete list of Maine town names (over 900 entities).  While this works, we
> have a few issues with it-
> -It’s a bit slow to load, at least initially
> -If you try to type the first few letters of a town name, the list does not
> scroll down toward your intended selection (it did in GM 2.2)
> -can’t scroll the list using arrow keys
>
> I don’t know if this has anything to do with the switch to Dojo or something
> else, but in any case, is there anything I can do to rectify these issues?
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> Geomoose-users mailing list
> Geomoose-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geomoose-users
>