Geomap: Issues when used within form

[jamespardey]

I've been using Geomap to select areas in forms, and for the sake of layout it's often easier to place the geomap within the form element itself. The new 4.0.31 unfortunately has a few minor issues for this usage:

The help button does not have a "type" attribute, causing it to act as a submit button by default.

The "step" parameter for the area of interest inputs will often cause the form to be marked invalid when an area is selected with the "Draw" button.

I've been able to replicate these issues on the working example page (v4.0.33 dev, it appears) simply by changing the <section> tags around the first geomap to <form>, within Firefox inspector.

For anyone else encountering the same issues, I've found a few quick kludges:

To prevent the button from submitting, add the following script (after jQuery has been loaded)

<script type="text/javascript">
$(document).on("wb-ready.wb", function() {
    $(".geomap-help-btn button").attr("type", "button")
})
</script>

With the WET-BOEW form validation plugin, if you're not using the AOI form results directly and transferring them to a different lat/lon entry field, the entire map can be ignored by the validator by adding its fields to the "ignore" selector. For example:
<div class="wb-frmvld" data-wb-frmvld=' { "ignore":":hidden, .wb-geomap input" } '>

[duboisp]

<form> element should not be used as a grid for layout.

What kind of layout are your expecting? Is there a reason you can't achieve your desired layout with the CSS grid?

[jamespardey]

To clarify, I'm not using <form> for layout, and it has no layout attributes. The geomap in use is within a form, to select an area for the request . It would be possible to move the geomap outside of the form, since the extent change event is being used, but would make the connection less direct.

The issues are, when a geomap is used within a form:

• The help button acts as a form submission button.
• With the AOI widgets enabled, on selecting an extent with the "Draw" option, the user coordinate entry fields are considered invalid, seemingly due to the "step" attribute being of coarser resolution than the data from the drawn area.

I was able to observe these in a browser inspector tool, by changing the <section> tag containing "Dynamic Map Example" to a <form> tag, on the Geomap - Working Example page. Then

• Pressing the ? will cause the browser to attempt to submit the form, reloading.
• Trying again, but first selecting an area-of-interest prior to pressing the ? will generally not submit, but instead give a default html5 validation error on the lat/lon inputs, since the values are probably not going to be a multiple of the step attribute.

[duboisp]

@jamespardey are you able to submit a PR?

• Add the type attribute and review the markup for the button in this JS file: https://github.com/wet-boew/wet-boew/blob/master/src/plugins/deps/geomap-lib.js
• Add a new section in the geomap documentation about the integration with the form validation plugin. - https://github.com/wet-boew/wet-boew/blob/master/site/pages/docs/ref/geomap/geomap-en.hbs

With the AOI widgets enabled, on selecting an extent with the "Draw" option, the user coordinate entry fields are considered invalid, seemingly due to the "step" attribute being of coarser resolution than the data from the drawn area.

What kind of precision is needed? How many decimal precision number you need for your use case? Currently it is configured to support up to 6 decimal precision. See: https://github.com/wet-boew/wet-boew/blob/master/src/plugins/deps/geomap-lib.js#L1172

[jamespardey]

I should be able to submit a PR in a week or so, provided I don't run into any issues getting the development environment set up.

As far as precision, our requirements are very coarse at the moment. 3 or 4 digits is more than enough. I imagine many users would need more precision than us.

Would rounding or truncating the AOI value to the step value in the 'boxend' callback (at least for the entry boxes) be an option?

[jamespardey]

Sorry, I'd intended to submit a PR a lot earlier. I'll be submitting with a different account, @jpardey, from personal equipment.

The "help button type" issue is very simple to fix, and shouldn't require any additional documentation.

For the step value rounding, a sensible approach seems to be to pull the step value from each input, and round the value from the box select to a multiple of that step. In making as few assumptions as possible to the value of step (say, 0.0002 or 0.00025), it might be a bit more complex than it needs to be, but seems more future-proof and user-proof. I can't see any changes that would be needed for the documentation. Any thoughts?

I didn't realize those commits would pop up in this thread. There are a few slight changes I'd like to make to the rounding code before submitting a PR.

Since this is basically two (very small) fixes, would you prefer one or two PRs for this?

[GormFrank]

Whenever you do a PR for this, do not forget to mention this issue in reference. Thank you!

[jpardey]

Thanks @GormFrank , and sorry for taking so long to submit such a minor patch, @duboisp .

Regarding the PR I finally submitted ( #8869 ):
I'd initially added a method to round depending on the step value, in case the user were to attempt to change it via scripting. That seemed pretty unlikely, though, and this just uses .toFloat(6). If it's needed I can integrate it again. It works with arbitrary step values, including with multiple significant figures (ie, 0.0025).

I'm not sure what documentation would be required, but I'd be happy to add to the English versions.

Tested on Windows (IE 11, Edge 41 and 83), Linux (FF 76), Mac (Safari 13), and Chrome 81 or 83 on all. I attempted to test on Safari for iPhone, but it seems like neither the AOI drawing or the help button is functioning. If this is a bug, I can investigate further.

[duboisp]

/cc @GormFrank