Import avoid_polygons from GeoJSON file

[noerw]

This would be useful for non-trivial avoid-situations, such as this.

[amoncaldas]

Every new route generated via user interaction made triggers an URL change. So the URL is expected to be always synchronized with the app state.

The avoid polygons are also synchronized wit the app URL. So every, polygon drawn on the interface makes the app "goes" to a new URL. So, if you set the URL compressing to off in settings/advanced, you can pass avoid polygons via URL. If the load avoid polygons is implemented, to keep this avoid polygons still working when the user interacts with the app, it should be passed via URL, what is already the case. It is important to remember that this is a client app and that it does not store data on a back-end.

If you have a suggestion of implementation that can deal with this suggestion in a better way, please let us know.

[noerw]

Hi @amoncaldas, I was just asking for an <input type="file" accept=".json,.geojson" /> in the UI as an alternative way to add polygons instead of drawing them :)

[amoncaldas]

Hi @noerw The input itself is the simplest part. The app flow to keep applying the restrictions related to the avoid polygons once you upload a file is the key point. For example, what would happen if you upload a file, then calculate a route and share the URL? What would happen if you upload a file with polygons and draw additional polygons using the drawing tools? We have to think about these points before planning a implementation :-)

[noerw]

Ah, now I think I understand the problem. If I didn't please ignore me 🙃

For example, what would happen if you upload a file, then calculate a route and share the URL?

Files wouldn't be uploaded, just stored to the client-side state for the avoid_polygons field (after basic validation). Changing the underlying input method from drawing to file-input shouldn't require a change in the URL state logic, as only the data source changes from drawing to file..

What would happen if you upload a file with polygons and draw additional polygons using the drawing tools?

Overriding the existing avoid_polygons state would probably be the simplest implementation, and seems intuitive for most use cases

• eg. selecting files several times: I'd expect a full override; the last file should represent the avoid_polygons state in the app
• concatenating inputs only seems intuitive when you have polygons from a file and want to add more by drawing, though I'm not sure this is a significant use case

[amoncaldas]

Hey @noerw

Thanks for the comments.

Yes, upload was not the proper term. I should have used load instead.

The thing is that every change in the app inputs lead to a synchronization with the app URL. So that it is expected that if you share/reload the app URL, everything will be rebuilt, including avoid polygons. Currently, when an avoid polygon is drawn:

• The app reacts by rebuilding an new URL containing the data about the polygons,
• The app is redirected to this URL
• The data is loaded from the URL
• The avoid polygons are redrawn using the data passed via URL
• The route is calculated using avoiding the polygons

If you change the places of the route, a similar flow is used, keeping the existing avoid polygons.

It is possible to implement the load avoid polygons from a file. At this moment I see two options:

Option 1 - The same existing flow when an avoid polygon is drawn us used to deal with the one loaded from a local file, then it must be synchronized/passed via URL. The URL length limit is relatively low, what would imposes limitation to the avoid polygons that could be loaded. This is the easiest option to implement. Is this what you expect?

Option 2 - The approach of not synchronizing the loaded polygons with the URL is used, then the URL would not represent what is being displayed. So sharing/reloading would make the app to "loose" the avoid polygons. If the loaded polygons are drawn on the interface (using the data from the loaded file) then the user might interact with it, resizing or removing some polygons (in the case a Multipolygon file is loaded). But as they are not synchronized with the URL then, they should not trigger a URL change. In this case, the app would have to be able to deal with two "types" of avoid polygons: the ones that are "stored in the URL" and the ones that are kept in the app js store, and use different strategies to deal with load, change and removal. This second option would potentially create some frustrations, since the users might see polygons on the interface and expect they can deal with then the same way. Of course not you, that is proposing this feature, but others that will probably expect the same behavior of the drawn polygons, been able just to draw and share the URL or just copy it and open in another browser/device.

Amon