geomoose / gm3

GeoMoose 3.0 Development. Please submit pull requests to the 'main' branch.

This is the readme file for GeoMOOSE MS4W package. If you haven't installed this application yet, please read the approriate INSTALL file for installation instructions.

This directory contains the following files and subdirectories:

 LICENSE
       -   this is the legal notice from the GeoMOOSE project

 README.txt
       -   This file.

 art   -   this directory contains the original graphics designed for
           the GeoMOOSE project. This directory is not web accessible.

 conf    - this directory contains the GeoMOOSE configuration files and is not web accessible.


 htdocs - this directory is where all web-readable files and
           subdirectories are located.  This is the directory that is
           referenced in Apache's Alias or Microsoft IIS's virtual directory.
           This folder contains the GeoMOOSE and Openlayers code along with the graphic images
           that make the user interface.


 maps    - this directory contains the data layers used by the
           GeoMOOSE demo application.  All datasets and MapServer mapfiles
           are contained in this directory.  This is not a web accessible
           directory.
           
 sphinx-docs  - this directory contains the scripts and documents to build a html version of documentation.

 tools -   this directory contains the scripts
           needed to "build" or "combine and compress" the individual javascript and css files into one GeoMOOSE.js library.  These scripts were adapted from the OpenLayers project (www.openlayers.org).
           These scripts require knowledge of python and are primarily only useful for developers who a modifying the javascript source code.
           These script have not been tested thourghly, so please use with caution.

You can checkout the full source code with your choice of:

git clone --recursive git://github.com/geomoose/geomoose.git
git clone --recursive [email protected]:geomoose/geomoose.git
git clone --recursive https://github.com/geomoose/geomoose.git

gm3's Issues

Download Vector Layer

There should be a complement to the "Upload" dialog for vector layers that can allow them to be downloaded to KML and GeoJSON.

HashTrack: Fails to load app on invalid layers in hash.

Github labels for project or saved responses

I'm still not entirely sold on the "reporter closes issue" method we use. I agree that it is a superior method since the person who reported and saw an issue is the one reviewing and closing. I'd like our method to be more obvious to the reporter if we are using it. (random example, #87)

We could add a label of "review" or "ready for review by reporter" or we could use saved responses where we just name the user and then put in a saved response. A few proposed saved responses below.

[@theduckylittle] [work has been completed on this issue and is ready for review visible in https://demo.geomoose.org/3.0/desktop/. Please review and test, reporting results here..]

[@theduckylittle] [work has been completed on this issue and is ready for review. This is not visible in https://demo.geomoose.org/3.0/desktop/ and requires an independent configuration for testing and review. Please review and test, reporting results here.]

[@theduckylittle] [work has been completed on this issue and is ready for review. This is not visible in https://demo.geomoose.org/3.0/desktop/ due to lack of access to specific hardware. Please review and test, reporting results here.]

[@theduckylittle] [work has been completed on this issue and is ready for review. This is not visible in https://demo.geomoose.org/3.0/desktop/ due to lack of access to url or configuration of reporter. Please review and test, reporting results here.]

Select can partially disable Measure

from #107

Select can partially disable Measure.

1. Select features with a line or polygon (and presumably select from: Drawing and Markup)
2. Switch to measure and either line or polygon will be engaged.
3. Clicking does not work, must change geometry selection type and then it works.

Jump-to-Scale

GeoMoose 2 provided users with a way to jump to a specific scale. It was a small component in the lower right-hand corner of the window. We should make this component available to developers.

Add a Length Input Type

GeoMOOSE 2.X had a special type of service input that would allow a user to specify a distance in their preferred units. gm3 needs the same capability.

Acceptance criteria:

1. A new input type that displays both a text field for the distance and a drop down for units.
2. The new class should be placed in src/gm3/components/selectInputs/length.jsx and appropriately extend TextSelect.
3. gm3/util.js should get a distance conversion function that takes in a length, a source units and a destination units. There are already functions that convert to/from meters. Those functions can stay there for now but we should have a new one that follows this prototype: export function convertLength(length, srcUnits, destUnits) where srcUnits/destUnits are one of m,in,ft,mi,km,yd.

This is the old 2.X implementation:

• The input: https://github.com/geomoose/geomoose-js/blob/master/geomoose/GeoMOOSE/ServiceInputTypes.js#L598
• The conversion function: https://github.com/geomoose/geomoose-js/blob/master/geomoose/geomoose.js#L808

Allow for specifying projections with the Mouse Coordinate control

Right now the mouse coordinates component shows up to three projections:

1. Map X,Y (in the default map projection)
2. USNG
3. Lat, Lon

A user has requested that the control be able to use an arbitrary projection. E.g. UTM-15. This can be useful for showing maps in web mercator but still allowing the users to resolve features to a coordinate system in which they are more comfortable (State plane, albers, UTM).

Hourglass for long running queries

Long running queries look a bit failed right now as they seem to lack any indication they are progressing. We should add a CSS trick or animated GIF (or both!) to make it look like something is happening for long running queries.

Marked as a bug because this really looks "broken" to the user even though nothing is functionally wrong.

Enter key does not make services "Go"

Right now the enter key does not appear to do anything.

When someone does a search or other interaction, the enter key should trigger the "Go" button.

Jump-to-Bounding Box Component

GeoMoose 2 has a component that allowed the user to specify a set of bounding boxes and labels. This component is missing from GeoMoose 3.

Measure bearing logic

The Measure logic for bearing here, incorrectly returns North and East for South and West.

Select Features from Drawing Layer

It would be nice if the user could select a drawn feature (like with the measure tool) when using Select Features.

Select Features using "Select from Drawing and Markup" allows for selectiong mutiple drawings but only uses the last one

Make various drawings and markup.

Select Features... "Select from Drawing and Markup," press and hold shift key, click and select multiple drawings, hit go. The selection returned in based only on the last selected drawing. Selections can also be of multiple geometries types (may be fine but may need to take that into account).

Selection should either be for all selected drawings or selection should not allow multiple selections or there should be an error message to only use one selection.

Measure and other aspects are probably a separate issue, or maybe this issue here should be a sub-issue of the general issue of handling multiple drawing selections. In measure, a user can select two drawings and it does not sum their area (also, the user is not prevented from selecting different geometry types).

Expand Measure to point (coordinate)

The Measure tools only measures lines (direction and length) and polygons (areas). Measuring a point could return a coordinate.

As a related aspect to this, Measure... Select From Drawing and Markup, (click a single point), gives no result.

Remove feature tool

There's no "remove feature" tool for vector layers.

Acceptance criteria:

1. The catalog gets a new tool that indicates a layer can have features removed from it.
2. Clicking on that tool starts a selector tool that lets the user select a feature on the map.
3. After clicking a feature the user is presented with a warning dialog. Ok removes the features, Cancel closes the dialog.

Clear previous selection on select features once a new selection drawing is initiated

From #107,

Right now the way select features works, once a selection is made, it remains selected until the Go button is hit again. This can lead to some screen views that look inconsistent.

This is an enhancement request to clear the previous selection once a new drawing is initiated.

From, #107 (comment), I'm not sure that we have the same understanding @theduckylittle. By "clear the previous selection", I mean the selection input geometry (unless it was a drawing and markup), any buffer geometry, and the selected and highlighted features.

Select Features defaults to all geometries

Instead of making a drawing or selecting a drawing in the drawing phase of Select Features, just hit, "Go." This selects all the features. This happens with all drawing options. It should probably select none and give some message that "Nothing matched your selection criteria" or "No results" some other useful message.

Linux install (maybe too early?)

npm ERR! peerinvalid The package react-dom does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer [email protected] wants react-dom@^15.4.2

npm ERR! System Linux 4.9.0-2-amd64
npm ERR! command "/usr/bin/nodejs" "/usr/bin/npm" "install"
npm ERR! cwd /home/rmorelli/www/gm3
npm ERR! node -v v4.7.2
npm ERR! npm -v 1.4.21
npm ERR! code EPEERINVALID
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR! /home/rmorelli/www/gm3/npm-debug.log
npm ERR! not ok code 0

Highlight layer should honour grid contents when available.

The grid and the highlight layer should be more tightly integrated to ensure that whatever is in the grid is shown in the layer.

Queries now have a "filter" property that can be used to pare down results on the client side. This should be honoured by by the service manager and by the highlight map.

File upload enhancements

1. Option to zoom to new features
2. Notify user number of features to be added (or failure to parse file).
3. Limit "Browse/Open" dialog to known file types (if practical)
4. Generic identify template created for uploaded features (is this even possible given the features are merged into the Drawing layer which might have features from many schemas?)

Using Measure after Identify accepts point input but does not return a result

Use Identify to click a few points.
Switch to measure. (notice that Draw Line, Draw Polygon, and Select from are not engaged)
Click around the map and points are registered.
No result is returned.
End Drawing (presumably still from Identify, not measure) is still active.

Add prop-types, prop-type definitions

prop-types

• We do not currently have a method for type-checking component props.
• Prop-types would be easy to add on a component-by-component basis as development continues
• We can omit the prop-types library from the production build, meaning little effective file-size increase

Fade and Unfade Layers

Implement opacity controls for individual layers.

Hash Track

GeoMoose 2 provided a mechanism for tracking the user's layers and location using the "#" in the URL. This super useful functionality should be in the new super useful GeoMoose 3.

How should we organize demo/sample applications?

Right now we have three ways of generating/packaging the demos:

1. geomoose/gm3:/demo
2. geomoose/gm3-demo-mobile
3. klassenjs/gm3-demos

None of them are great, but they all have their advantages too. So, how do
combine the approaches to one best version?

1. • +Being in with the source, simple packaging and easy to test/maintain
   • -Not a good example for others (layout)
   • -Duality of being "just for dev/testing" but is likely the only demo
     to be maintained.
   • -Easy to cheat and not notice (use stuff outside of dist, non public API)
   • -Easy to change at same time as lib means breaking changes in the lib
     are less likely to be noticed
   • -Only easily supports one demo (but that could be a very complete demo).
2. • +Uses npm for dependency management, but only for jquery
   • +Provides isolation between the lib and apps that depend on it
   • +Easy to understand layout - uses npm in a standard pattern
   • +Can easily be packaged as a zip and will just work
     (with node_modules pre-populated)
   • -Not at good example of how to install for real
     • -Duplication of config between mobile and desktop
     • -node_modules is (necessarily) web server accessible
3. • +Uses npm for dependency management
   • +Provides isolation between the lib and apps
   • +Most like what I would want to actually deploy
     • +Shared configuration (mapbook.xml, config.js)
     • +Shared libraries
     • +Desktop and Mobile both available
     • +Structure to add more "demo" apps
   • +Possible to build zip/tgz/ms4w.zip packages directly via grunt
   • -Most complex layout and build
     • -npm only puts stuff into node_modules so there are a lot of
       file copy operations to build a usable directory structure.
     • -This makes it more fidgety to substitute a git repo for a npm
       resource.
   • -package.json has to include deps for all demos, but can't document
     which deps belong to which.

Thoughts:

• We have a goal of easy updates.

• We have declared geomoose/gm3 is a library

• So everything in demo (or equiv) is now part of the user's app.

• How do the user app (test.js/index.html) get updated?
  Sure, The user does it. But how do we communicate that? How do we
  provide help for that on the list?

• Semver then means minor and patch changes to gm3 cannot break user apps.

How many demos should there be? How many can we realistically maintain?
Possible ideas for additional demos:

1. a non-mapbook driven demo
2. a responsive demo
   can we put mobile and desktop in the same folder and have the JS
   pick (window.location) based on browser ("Fetch Desktop Version"
   on mobile)
3. Minimal UI embedded in another page

Services are a mess right now too:

1. How does a user add a service?
   Shouldn't it be defined in their app and registered with the library
   rather than essentially require a fork of GM3?
2. Why aren't standard services compiled?
   And thus need to be listed separately in index.html?

Hash Track + Opacity?

Not sure if this is strictly necessary but opacity for a map-source can now change. It may be worthwhile to track it.

Add lines to Drawing and Markup

Are issues on 3.0 helpful?

Drawing and Markup does points and polygons but not seemingly lines.

Feature Editing

Implement WFS-T layers.

• Geometry editing
• Attribute editing

We'll use TinyOWS as the example WFS-T server but GeoServer should be tested as well.

Activate (or reactivate) Super Tab when returning to a tool

When using a tool, let's say Select Features, if you select another tab without hitting "Close" or "Go" (or a different tool), hitting the tool again doesn't bring the tab up.

Click "Select Features", click on the catalog tab, turn a background layer on or off, click "Select Features", continue staring at the catalog tab and notice that the Super Tab is not activated. Either click a different tool (Identify for example), or the Super Tab (and optionally "Close" or "Go") to continue.

Improve Default Toolbar Styling

The "Dev Demo" lives in ./demo. The current toolbar is pretty bland and difficult to read. A double lose!

Acceptance Criteria:

1. Make the text size a bit larger so it's more readable.
2. Add a few icons. We are including Font Awesome and Map Icons webfonts already and so I don't feel we need to go for additional art work for purposes of the demo.
3. Play around with adding color to a few icons to make them more distinguishable to the users.
4. All of the changes should be in src/less/toolbar.less and use appropriate less syntax for including the icons. The catalog.less file can be used as a reference.

Which tools toggle on and continue to repeat and which need to be re-invoked for each repetition?

Measure and Identify toggle on and continue to perform the same function until they are somehow switched off. Select Features needs to be re-invoked every time that a selection is desired.

Should toggle on tools like Measure and Identify visually stay "on" in the icon until they are switched off?

Which tools should toggle on and which shouldn't?

Semi-related, which tools should have "Go" buttons and which should just automatically happen?

Create a nominatim geocoder service

The Bing Service already exists but it would be nice to have a version that uses the open source geocoder from OSM.

HashTrack and "Built-in" Layers

Two different types of "smart" layers have been added to the application:

1. "results/*" there are two different results layers. One for display the results of a query (and honouring the client side filters for it) and one for hovering over the results in order to see a 'selected' geometry on the map.
2. "selection/selection" While writing the buffer tool it was important to preview what the user was going to get when they selected applied a buffer. This required having two "seleciton" layers. The first selection layer is built-in to the OpenLayers map and is a consistent target for the OpenLayer's controls to use. the second selection layer is the map-source "selection" with the layer "selection" which is managed by the map to preview the actual selection features as the user gets them. This is added with PR #88 .

However, when a user decides to remove "results/" or "selection/" layers from the hash then when the services render they can be missing those layers and not see the highlighted results or the selection preview. i have a couple of thoughts on this:

1. The layers could be forced on anytime they get new data or something is expecting them to be visible.
   This seems like a reasonable "hack" but I do feel like these layers can ALWAYS be on and it will not effect the user experience with how OpenLayers now handles vector layers (that is OL3+ vectorizes them).
2. Add a new "hide from tracking" or "alwaysOn" status for the layers.
   I actually feel this is a reasonable thing to do. Some layers are internal, they should always be on and they're lynch pins for good functionality.
3. Put these layers BACK into the Mapbook and let users add them to the catalog.
   This certainly is an approach and offers a lot of flexibility. There could even be some CONFIG variables used to set these with reasonable global states and everything. BUT I honestly believe there were some times where we really put effort into maximum flexibility on features and lost consistency from a user's perspective. Yes, a savvy administrator had more tricks available to them but we had a harder time managing state and in the new version I think we'd have a more difficult time doing testing. The corner cases start growing out of control.

Identify can hang on Measure input

Click Identify (don't click anything else here), click Measure, select Draw Line, draw a line, click Identify. Identify tab is no longer functional.

Source maps in production

The source map: geomoose.min.js.map is a bunch of webpack URLs which don't map to anything outside a "grunt serve" environment. Thus, in production (apache/nginx server) the browsers debuggers can't make use of this info. As it is large, I wonder if we should consider omitting this file from the build or from the packages.

Client Side Buffer Oddities

Continuing the discussion here from PR #88 since it has been merged:

@elil Using 8487451 on https://demo.geomoose.org/3.0/ I did select features, draw polygon, change buffer to 500 ft, go and it appears to show the original polygon, the buffer, and the selected parcels. Is this working as you think it should?

I see multi-point is only using the last point. Select Features, Draw Multi-Point, set buffer 500ft, go:

I also see that the buffer setting stays set to what it was when re-entering the Select Features tool, but the form elements are set to 0ft. Changing the buffer distance form element updates the buffer to the value displayed.

Layer Re-ordering Controls

1. We need to add "Up" and "Down" controls to the catalog / Visible Layers to allow users to visually sort the layers.
2. Visible Layers should be ordered by the layer's Z-order.

"Ending" Map Interaction

There are cases where the user will switch away from the Super tab but leave an interaction with the map turned on that is not simply "navigate."

There should be a big button on the map that says, "Stop [ Interaction ]" that cancels out any interaction the user may be performing at any time. This gives a clear indication what tools is selected on the map even if the Super tab is not open at the time.

I think this could be a big usability win and really provide clarity to what tool is active when.

HashTrack State Upgrades

It would be useful if HashTrack could restore the visible state of the map so that sharing the URL with someone else or bookmarking it for yourself would restore the map as it looked before.

Currently, the following are tracked:

• Map center and scale
• The list of visible layers

To restore the map to its previous visible state, at least the following would be, in addition, required:

• Layer Z-Order
• Layer Opacity
• Drawings
• Query results

While all of this state may be technically trackable, doing so is a lot of data and would produce exceptionally long URLs that in many instances would exceed the lengths allowed by the browsers. This could be somewhat mitigated by compressing the data but that wouldn't remove the length limitation and would also make testing and manual inspection/changing of the URL significantly more painful and thus may not be worth the complexity. Thus, we will not be able to reliably track everything and will need to be selective about what is and isn't tracked.

Grid results and tab results behave differently

Hovering over grid results highlights that particular parcel in the selection. Hovering or click on results in the super tab does not do this. It would be better if the grid and tab behaved in a similar manner.

Hover could perhaps also be clicking instead.

Identify broken on City and County Boundaries layer.

Select some features.
Identify, click on map.

Select features still listed in Super Tab, Grid, and Map. Identify results don't show up.

Reference Map

Create an example of a reference map for use in GeoMoose.

This is a bit of a "vintage" feature in web-mapping applications but GeoMoose 2.X did it so we should probably investigate giving it a nod.

Zoom to feature in results does not work

Clicking the "Magnifying Glass" icon (presumably a zoom to feature tool) in a selection does not zoom to the feature. This is both the case in the supertab and grid.

Get a selection by search or select.
Click on the zoom to feature icon in the supertab and grid.
Zoom is not changed.

Buffered Selection

User's will want to be able to select features using a drawn geometry and a buffer. They also want to select features from a layer, buffer those features, and select a set of features.

The classic example: Buffer a parcel by 1,000 feet.

To do this, we're looking to use JSTS. This is a big library and adds a lot to the deliverable size. Care should be given to prevent the library from bloating much more. Making JSTS optional may need to be on the table for folks who won't need the buffering functionality.

Activate focus of search box when search icon is clicked

If you click the Search Parcels icon and blindly start typing the text does not go in the search box. It would be better if that text went into the box. If there were more than one box, it could perhaps be configurable which box was the default (although ideally search would be effective enough that only one box is needed).

Related, #61 since a common use would be to click Search Parcels, blindly type your search without clicking in any boxes, hit enter, see results.

Tests don't run on Windows

npm test fails to run any tests.

C:\ms4w\apps\gm3>npm test

> [email protected] test C:\ms4w\apps\gm3
> node node_modules/jest/bin/jest.js --coverage ./tests/

No tests found
  70 files checked.
  roots: C:\ms4w\apps\gm3 - 70 matches
  testMatch: **/__tests__/**/*.js?(x),**/?(*.)(spec|test).js?(x) - 4 matches
  testPathIgnorePatterns: \\node_modules\\ - 70 matches
  testPathPattern: "./tests/" - 0 matches
----------|----------|----------|----------|----------|----------------|
File      |  % Stmts | % Branch |  % Funcs |  % Lines |Uncovered Lines |
----------|----------|----------|----------|----------|----------------|
All files |  Unknown |  Unknown |  Unknown |  Unknown |                |
----------|----------|----------|----------|----------|----------------|

Select Features by "Draw Multi-Point" does not draw or select

Trying to draw and use a Multi-Point for Select Features does not work. It does not draw any points, it does not activate the "End Drawing" option, and it does not select anything.

CONFIG should be able to defined the default tools

In the current code, all of the tools are turned off for all layers by default. It would be nice for admins to have the ability to turn ON a set of tools by default and then choose to turn them off on specific layers.

Clear All (and maybe Remove Feature) drawing tools should ask for confirmation

Projections - The Final Answer

@klassenjs Here is our dumping ground to discuss how feature projections once they hit the services.

EPSG:4326
Pros:

• Familiar coordinates at local and global levels. This is particularly useful for things like Zoom-to-point and bounding box definitions.
• "Easy" reprojection
• Relatively simple to make consistent across the application.
• KML and GeoJSON spec 4326 as the bespoke projection.
  Cons:
• Wasted energy if the service can or does return map coordinates.
• JavaScript struggles with super-high precision floats, so very-very-local level survey stuff could get "off"

"Native Map" Coordinates -- Currently 3857
Pros:

• The coordinates that are in the dataset are likely to be the ones seen in the map.
  Cons:
• Native 4326 datasets will need to get "projected in" to the application (KML, GeoJSON)

I like the familiarity of using 4326 in places. It means the underlying data projection could change and things like templates don't need to change. So ostensibly you could configure a version of the application in "local" coordinates for more precise survey work and web-merc for general consumption (to use widely available imagery) without needing to change anything in the mapbook.

FWIW, neither decision effects measurements or buffers as that casts everything to a relevant UTM projection to ensure the measurements are valid.