Different GEOCODING_DISAMBIGUATION and MAPIT_ID_WHITELIST settings in one installation

[Jon Kristensen]

Hi!

We're working on setting up a separate cobrand for a specific municipality to be used alongside our regular “FixaMinGata” cobrand. Ideally, I think we would like to use the same FixMyStreet installation (“/var/www/fixamingata.se/fixmystreet”) for both cobrands.

So far I've used the regular FixaMinGata installation, just adding a separate cobrand.

However, now I'm in a situation where I would like to have municipality-specific settings for MAPIT_ID_WHITELIST and GEOCODING_DISAMBIGUATION. In other words, I would like the two cobrands to have different MAPIT_ID_WHITELIST and GEOCODING_DISAMBIGUATION settings.

Is this possible without adding a separate FixMyStreet installation?

Thanks!

All the best,
Jon

[Jon Kristensen]

Hi, again!

Just a quick update:

I discovered conf/cobrands and tried to put configuration settings in conf/cobrands/$moniker/general (with and without a yml extension) but the settings didn't seem to kick in.

$ cat conf/cobrands/$moniker/general
GEOCODING_DISAMBIGUATION:
  bounds: [...]
  country: 'SE'
  town: '...'
MAPIT_ID_WHITELIST: [ ... ]

All the best,
Jon

[Matthew Somerville]

Hi,

No, that's some very old historic thing, for having cobrand config in a separate repository I think it was, nothing uses that any more (looks like I removed it in 20113bad5b but missed that file).

On your original question:

* For GEOCODING_DISAMBIGUATION, yes, you can override what this is on a per-cobrand basis by adding a `disambiguate_location` function to your cobrand .pm file returning the data instead;

* For MAPIT_ID_WHITELIST, I'm not sure exactly what you're after here. I may well have missed something, but I don't think you need to have different values on a per-cobrand basis - I would put all the MapIt IDs you wish to be used in MAPIT_ID_WHITELIST, then you can restrict which of those areas a body covers using the admin interface.

ATB,

Matthew

--
You received this message because you are subscribed to the Google Groups "FixMyStreet" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fixmystreet...@mysociety.org.
To view this discussion on the web visit https://groups.google.com/a/mysociety.org/d/msgid/fixmystreet/0071f060-0ccb-494e-9f4d-73ccb6643258n%40mysociety.org.

[Jon Kristensen]

Hi!

Thanks a lot!

Can setting bounds in disambiguate_location result in the map being panned?

If I use only the disambiguate_location method in FixaMinGata.pm, a search for “Torup” results in https://fixamingata.se/around?lat=56.95354&lon=13.07446&js=1&zoom=2 (which is correct).

However, if I extend from FixaMinGata.pm and specify...

sub disambiguate_location {
    my $self    = shift;
    my $string  = shift;

    return {
        %{ $self->SUPER::disambiguate_location() },
        bounds => [ 56.8236518, 12.8207981, 57.1138647, 13.6935731 ],
    };
}

... a search for “Torup” results in https://hylte.fixamingata.se/around?js=1&zoom=0&lat=56.9713&lon=13.26638 (which is incorrect).

I would expect, and like to get, the same coordinates for both searches.

Torup in Hylte kommun (https://nominatim.openstreetmap.org/search?q=Torup,%20Hylte%20kommun&format=xml) is contained within Hylte kommun (https://nominatim.openstreetmap.org/search?q=Hylte%20kommun&format=xml). Hylte kommun's coordinates are what's specified in the bounds array above. In other words, the bounding box for Torup should be contained within the bounding box for Hylte.

Any hints would be appreciated. 😊

All the best,

Jon

[Matthew Somerville]

Hi,

After some investigation, I think I've worked it out - it /is/ working on your site and originally going to zoom=2, lat=56.95354, lon=13.07446 as you want - but then you have a fixmystreet "area" set up (ID 68), which is once loaded, trying to zoom to the bounds of that and zooming out to zoom=0 and changing the centre of the map. Hope that's helpful.

ATB,

Matthew

[Jon Kristensen]

Thanks for looking into this, it was very helpful! 🙏

I can confirm that removing areas_on_around fixes the panning problem.

Is there some way I can keep areas_on_around set (in order to get the border on the around page) but prevent the panning?

All the best,

Jon

[Matthew Somerville]

On Wed, 25 Oct 2023 at 17:14, Jon Kristensen <j...@nejla.com> wrote:

Is there some way I can keep areas_on_around set (in order to get the border on the around page) but prevent the panning?

I think the bugfix is to change, in web/js/map-OpenLayers.js, the line:

    if (!qs.bbox && !qs.lat && !qs.lon) {

to:

    if (!qs.bbox && !qs.lat && !qs.lon && !qs.pc) {

(If you've come to the page with a postcode search, you don't want it to change the bounds, just as if you'd come via a lat/lon).

Happy to accept a PR with that if that works for you.

ATB,
Matthew

[Jon Kristensen]

Hi again!

Awesome! 🥳 The change seems to work well and I've configured it in production on FixaMinGata.

Absolutely, I'll create the pull request, but I'm thinking perhaps I can wait for a little while just to see if someone reports an issue with the change. Please let me know if you disagree and I'll make it right away.

By the way, I just noticed that reports outside of Hylte are displayed when using the around view, for example here:

https://hylte.fixamingata.se/around?js=1&zoom=3&lat=57.75293&lon=12.05197

Is there a way to hide reports outside of the body in a cobrand?

All the best,

Jon

[Jon Kristensen]

Hello, again!

I managed to hide the reports outside of Hylte by overriding problems_on_map_restriction (I also set problems_restriction and updates_restriction).

Returning 1 from is_council seems to require changes related to owns_problem due to default/problem-confirm.html, otherwise we get a “is not responsible for this type of problem” when clicking on the confirmation link. Any suggestions on how to deal with this would be appreciated.

I'm also wondering if there's a way to disable problem reporting outside of Hylte for this specific cobrand. It would be great if we could present a link to fixamingata.se if someone tries to do this.

Finally, I'm curious if postcode searches that resolves outside of Hylte can be disabled. For example, searching for "415 16" on https://hylte.fixamingata.se/ resolves a location in a different municipality/body.

All the best,

Jon

[Matthew Somerville]

Hi,

Yes, my reply to your previous email would have been to use the *_restriction functions in the cobrand, as you've found :) You can use ->to_body(ID) to restrict to reports sent to a particular body, that's generally what we do. You shouldn't need to set is_council to 1, I think, that doesn't really do anything much (might have missed something though).

> I'm also wondering if there's a way to disable problem reporting outside of Hylte for this specific cobrand. It would be great if we could present a link to fixamingata.se if someone tries to do this.

Yes, we can do this - if you copy the area_check/responsible_for_areas/area_check_error_message functions from UKCouncils.pm, and have a `council_area_id` that returns the relevant MapIt area ID, that should do what you want, I think. This might also work for the searches outside the area as well, I think the same code runs at that point. We could factor out that code into some form of shared 'restriction-on-area' situation or something like that potentially.

ATB,

Matthew