Let user upload GeoJSON file of nogos

[Phyks]

Hi,

This is a very first draft of the ability to create nogos from a GeoJSON file or URL.

This is definitely not yet ready to get merged, I'm just opening this to get feedback, especially on the UI part.

This can be tested on Paris using this GeoJSON export of impacting roadworks for instance: https://opendata.paris.fr/explore/dataset/chantiers-perturbants/download/?format=geojson&timezone=Europe/Berlin.

TODO:

• read a nogoWeight feature property from the GeoJSON if present and only use the weight input from the dialog as a default if not.
• read nogo circles
• Add a buffer geometry feature?

Best,

[alesarrett]

Just as a feedback, I'm asking whether the input file can accept also line features in addition to areas. The use case might be simply to pre-select some roads that for some reasons are not usable, and upload portions of roads to be used as no-go "areas".
Another clarification is the nogo weight: would it be in your idea a single weight to "calibrate" the no-go?
It would be also great to provide a way to assign different weights to the no go areas/lines in the GeoJSON and to make this understandable by the routing algorithm...

[Phyks]

I'm asking whether the input file can accept also line features in addition to areas.

It is currently accepting line and polygon features from GeoJSON file. The use case I have in mind is precisely to upload opendata features about road works to avoid them :)

Another clarification is the nogo weight: would it be in your idea a single weight to "calibrate" the no-go?

This is a penalty used by BRouter under the hood to compute routing. This is basically a cost proportional to the distance travelled inside the nogo area.

It would be also great to provide a way to assign different weights to the no go areas/lines in the GeoJSON and to make this understandable by the routing algorithm...

This is already possible in the routing algorithm but not in the frontend yet. See #144 for some discussion about it.

[nrenner]

It would be also great to provide a way to assign different weights to the no go areas/lines in the GeoJSON and to make this understandable by the routing algorithm...

This is already possible in the routing algorithm but not in the frontend yet. See #144 for some discussion about it.

Although there is no UI for it (yet), the client-side code does support individual weights, you can already pass them with a URL?

So I guess it might make sense to read a nogoWeight feature property from the GeoJSON if present and only use the weight input from the dialog as a default if not.

This would probably also enable to add an export option for nogo areas to GeoJSON later and importing them with this feature again (in part related to #16 and abrensch/brouter#91).

[Phyks]

I pushed a new commit to improve the handling of loading the nogos from geojson. Nogo weight should be used as a fallback value now and points can be imported as circles.

The main remaining issue is that the URL hash is not updated when loading the geojson file.

By the way, @nrenner do you know any easy way to buffer a geometry in meters in Brouter-web? I usually project in a local representation with meters as units, do the buffering and project back to WGS84 but this is not very usable on a worldwide basis :/

[nrenner]

The main remaining issue is that the URL hash is not updated when loading the geojson file.

Updating the route and hash can be done by adding the following calls after nogos.setOptions:

    updateRoute({
        options: nogos.getOptions()
    });
    urlHash.onMapMove();

By the way, @nrenner do you know any easy way to buffer a geometry in meters in Brouter-web?

For example with Turf: http://turfjs.org/docs/#buffer

To work with Leaflet layers I think you would need to convert with toGeoJSON() methods and back with GeoJSON layer.

What is your use case?

[nrenner]

Some additional thoughts:

• UI
  • As loading additional things is planned (e.g. tracks Load GPX track #30), it might be better to already create a "Load" dropdown menu (like "Download") with "Nogos" as single item for now
  • Not sure, but I personally would prefer "Load" instead of "Upload", as it's not really uploading to and storing on the server, just loading into the browser, what do you think?
  • I would prefer About being the last nav item
• Why is the nogo weight mandatory now? Wouldn't it take the default prohibitive value on the server if not set?
• i18n keys are missing (translatable since i18n: translate website #159), but we also can do that afterwards
• We haven't used Promise and fetch yet. I have looked into browserslist tools like browserslist-generator to check if we have visiting Browsers that don't support them and found a few. But I would need to check further and with current logs and will merge as is for now.

[Phyks]

What is your use case?

Oh, great, I missed that Turf could do buffering! Typical use case is when using raw OpenData files for road works for instance, sometimes the lines / polygons are very narrow (in the sense that they cover only the very particular portion of the street which is impacted) but not well positioned (with a slight offset or not covering the whole highway from OSM data). Using a bit of buffering is a very easy solution for this. Another reason is when the polygon for the nogo only cover half of the road, but you expect the road works to actually have impact on a much larger area (traffic jam, etc).

Thanks for all the feedback, I'll have a look at this during the weekend and update the PR!

[Phyks]

Hi,

I should have reworked this code a bit to include the remarks (i18n, UX etc) as well as the buffering. Everything is squashed and rebased against the current master branch.

The UX part is probably sub-optimal. I think a progress bar could be shown during loading and processing of GeoJSON file for instance, but this is probably fine for a first draft.

This should be ready for review and (hopefully) mergeable. Let me know if you have any question or doubt on this.

Best,

[nrenner]

Thanks for the update and your contribution!

The UX part is probably sub-optimal.

There is always room for improvement, it's fine as it is.

[Phyks]

Thanks!